Reprise du message précédent :
Petite question archi BDD :

J'ai une appli qui permet de faire des bons/devis/factures dématérialisés avec une table Bon de commande, une Facture, une Devis etc. (Ces tables sont similaires). Ce sont juste des "types" de features que l'on a dans l'appli.
Dans ces bons/devis/factures sont reliés à une table "Products" en many to many.

En gros, pour chaque "type", on rajoute X produit, et on génère un beau PDF. Tout fonctionne, sauf que je dois faire évoluer l'appli.
Avant, on pouvait ajouter un produit qu'une fois. Maintenant on peut ajouter un même produit plusieurs fois dans le même document. Et vu que ma table de jointure est juste id_produit - id_invoice par exemple, bah j'ai un soucis d'unicité.

Du coup j'ai deux choix :
- Soit ajouter une colonne "products" dans order/invoice etc. sous forme d'un json, qui sauvegarde les produits à un instant T. Avec nom, description, prix. (Il me faut une sauvegarde à un instant T car si le mec modif le prix d'un produit 6 jours plus tard, je veux que la facture généré 6 jours avant garde bien l'ancien prix). L'avantage c'est que du coup j'ai direct ma liste de produit à un instant T.
- Soit je rajoute une table many to many avec des champs custom, qui seront en fait prix, nom, etc. une copie de la table product quoi. Du coup chaque ligne aura un id généré, et j'aurais plus de problème à avoir X lignes avec le même id product et le même bon/facture. Ça me semble plus propre qu'un Json dans une base.

Je sais pas si je suis très clair.

T’as deja une table m2m, c’est juste qu’actuellement t’as une contrainte d’unicité sur (produit, facture). Tu peux l’enlever. Ou alors tu ajoutes un compte et quand tu ajoutes un produit si le lien existe déjà tu l’incrémentes juste de 1.  
 
Si t’as besoin de plus de meta données genre des remises, t mets un o2m “ligne de facture” qui a toutes les données à l’intersection du produit & de la facture, c’est ta table de jointure “riche” si tu veux. Pas de contrainte d’unicité dessus, tu peux avoir 2 lignes avec le même produit pour la meme facture mais genre des taxes ou remises qui diffèrent.

Tout pareil que masklinn, pour moi tu transformes ta table de jointure en "ligne de facture" avec nb d'articles, prix unitaire, taux de tva, remise accordée...c'est assez classique.

Je suis plutôt dans le deuxième cas.

Car en effet, j'ai besoin d'autres champs. J'ai besoin de recup le prix, description etc. à un instant T. Mais je dois ajouter un dessin, des champs custom etc.

D'ou le fait de soit passer m2m classique avec champs custom comme évoquer. Soit de simplement foutre un json avec tout dedans.

Merci pour vos avis.

 
Le json avec tout dedans je comprends pas, perso.  
Pourquoi pas un jpeg de ta facture tant que t'y es, si tu veux stocker en base des données inexploitables?

Bah le json reste exploitable quand même.

en sql? Bon courage...

Non pas direct en SQL. Mais j'ai pas besoin.

En gros l'appli est assez classique. Je passe par typeorm qui me recup les champs, je renvoie, et c'est côté front qu'il y a des choses ou non à afficher.

Le seul truc à gérer c'est qu'on peut modif une facture, la supprimer ou la transformer en avoir. Pour le bon, c'est simplement une création/suppression. Du coup la liste des produits ou autre, je m'en moque un peu, en gros j'ai pas de traitement à faire dessus.

 
Aujourd'hui.
Il se passe quoi le jour où ton client te dit qu'il aimerait bien pouvoir sortir un historique des ventes de ses produits, avec les prix et les remises associés? Tu parses tes json un par un pour en extraire les données?

J'lui dit qu'il me paye et qu'on verra pour la suite déjà.
Non mais effectivement c'est plus propre. C'est pour ça que je demandais l'avis, c'est juste plus de taff à faire.

https://www.postgresql.org/docs/9.4/functions-json.html

Postgres le fait bien.  
 
Mais c’est plus indiqué pour un sac de meta-données qui n’est pas l’utilité primaire ou pour lequel les tables supplémentaires seraient plus problématique qu’autre chose.  
 
Ici c’est pour le cœur du truc & la table existe déjà donc le json me semble pas indiqué.

La table existe pas vraiment. Enfin c'était une m2m généré tout seul par Typeorm juste pour avoir un lien invoice<->products, mais je m'en sert pas, vu que c'est pas les prix à un instant T. J'avais juste ajouté cette relation "au cas où".
Du coup j'avais justement un champs "informations" qui était comme tu dis un sac de méta-données où je mettais aussi la liste de produits avec des infos en plus.

Vu que là on refait propre, je pars sur une OneToMany. Cette table servira pour les X autres tables (Order, Invoice) et contiendra l'id d'un produit, l'id de order/invoice et les X champs de la table product que je souhaite save à l'instant T.

En fait c'est surtout qu'a la base, y'avait pas de table produit, c'était des champs ajoutés au pif par le mec côté front etc. d'où le fait d'une sauvegarde en json au tout debut de l'app.

3/ tu ajoute un champ en autoincrement sur ta jointure et tu fais péter la contrainte d'unicité

edit : grillé

alors oui, dans t atable de jointure, tu ajoutes la copie des champs de la table product (eventuellement dans un json)

Quand tu veux parcourir tes produits pour les ajouter à une commande : tu parcours la table product

Quand tu veux générer ta facture : tu recup le json (mais garde quand même les champs importants et communs dans de vrais colonnes, tu te simplifieras la vie pour faire les cumuls/moyennes)

Du coup j'ai surtout plus besoin de JSON. Des vrais colonnes ca fait le taff.

Question front pour ceux qui pratiquent.
J'ai une appli web java avec un front à l'ancienne et j'aimerais avoir quelque chose d'un peu plus sympa.
 
Dans la partie plus spécifique, je vais avoir un gros bloc d'icônes, j'aimerais pouvoir les réorganiser par groupes et les trier en fonction de filtres choisis par l'utilisateur, côté client. Quel est le meilleur moyen de faire ça ? En termes de manipulation du DOM, etc. Je suis largué sur les libs, les technos, etc.
 
Illustration pour vous montrer l'idée :
 

...et t'appelles ça du sql?

C'est typiquement le genre de trucs qui me font bondir, perso...si tu veux des données structurées et exploitables, ça tombe bien un sgbdr c'est fait pour ça.
Si tu y mets des données non exploitables sans retraitement, c'est qu'il n'y a aucun cas d'usage qui justifie d'y accéder directement.

 
dans order/invoice, tu dois avoir une column price avec le prix de l'item à l'instant T de l'ajout. (A moins que je ne saisisse pas bien ton problème)
 
Edit: oulà j'étais très en retard.

 
Je dirais Random.nextInt(4) parmi Angular, Ember, React et Vue.

 
Pas directement dans la table order/invoice.  
 
Mais tqt c’est bon, j’ai ma solution « propre ».

Grid p-e?
 
Tu définis des layouts pour les contenus & tu peux positionner tes objets spécifiquement.

Je vais avoir besoin de quelques précisions de plus les gars, je sais pas par où commencer

En gros actuellement côté front, tu as une liste d'icones. Et maintenant, tu veux ajouter des filtres pour que ça range les icônes selon les groupes/filtres ?

Ou tu veux du drag and drop aussi ?

Le json est la pour les champs variables,

Des fois on n'a pas vraiment envie de multiplier des colonnes presqueq tout le temps vide, et ce n'est pas pire que la jointure sur une table variable_int/double/date/variable_text....

Et une colonne json est parfaitement exploitables en postgresql, tu peux faire tes jointures , tes index,...

 
Juste des filtres, pas de drag & drop.
Y'aura du comportement au clic sur les icones mais ça viendra plus tard ça je pense.
 
Je voudrais me servir de ça comme d'une intro vers ce qu'est un front JS moderne, je suis pas forcément prêt à me jeter dans les pipelines de build nodejs complexes, mais j'en suis encore à HTML + CSS + jQuery, ce qui est assez limité.

Pour faire ton truc, tu n'as pas forcément besoin de lib/framework si tu veux pas t’embêter avec ça. Tu fais juste ton algo en JS pour split ton tableau d'entrée et ensuite pour l'affichage j'aurais effectivement utilisé du Flexbox. Comme ça tu peux avoir un affichage dynamique plus facilement.

Après ajouter React et faire le rendu avec du JSX ça se fait assez facilement.

...parce-que...?

franchement pour faire ce que tu décris, pas besoin de jquery ni même de react ( qui incluera forcement une phase de build plus ou moins grosse). Je resterai en JS standard. Du bon vanilla des familles.
Par contre c'est différent si tu veux te servir de ça comme marche pied vers un client plus lourd

exemple : mes ecrans de jeux ont systématiquement la même dizaine de colonnes, dont certaines pour lesquels je suis bien content d'avoir les jointures. Mais il y a aussi des colonnes spécifiques à chaque écran (exemple simple : pour une question à choix multiple les propositions et les bonnes réponses). Tout ça ne pourrait pas être stocker de manière confortables dans un SGBDR , a moins d'aimer vouloir faire péter tous les outils de gestion. De même ajouter un nouveau type d'écran de jeu ne me fait faire aucune modif dans ma base de données.

Dans mobops, je stockais les colonnes indexables/cherchables dans des vrais colonnes, le reste en JSON. C'était super confortable pour ne pas avoir à se battre avec les migrations de schéma.
La seule étape un peu pénible est lorsqu'on doit (rarement) rematérialiser un champ.

Dans mon cas, je trouve qu'il est efficace de ne pas trop s'arreter sur le format Relationnel ou non de la base, il y a une certaine convergence: d'un côté on utilise une base documentaire avec des références , de l'autre une table relationelle avec ou/des champs sans schéma

Chez nous ça nous arrive aussi d'avoir des champs json en base, pour pas avoir à faire d'eav par exemple.

Un ancien collègue me propose de le rejoindre chez le copain de Pythagore....
A la louche si ça se faisait je perdrais un environnement de travail super sympa dans une boîte dynamique dans son fonctionnement, mais qui manque parfois de process et de cadres , et je gagnerait des thunes (je sais pas combien, mini 10%) un environnement plus carré mais beaucoup plus rigide, une convention collective avantageuse, un très gros CE, et la possibilité de rentrer dans une autre entité du groupe.
A mon age, je me dis que ça serait le choix de la raison, mais boarf.

A terme le but est d'avoir un frontend moderne, mais c'est effectivement pas une nécessité tout de suite.
Y'a moyen de pas se faire chier avec du vanilla en 2019 ? Niveau cross browser ? Y'a des références accessibles sur les bonnes façons de faire ?

Y'en a qui bossent avec des VM sur Mac ?
 
C'est relou le clavier sous Linux qui reprend celui de Windows

des fois tu peux mettre un clavier mac dans les linux de VMs

J'vais regarder ça

Le vanilla est bcp plus simple maintenant qu'il y a 10 ans, si tu ne supporte pas IE
Ton pire navigateur sera safari iOS, le reste réagit quasi pareil

Caniuse

Thx !

 
Tu en ajoutes tous les deux jours, des types d'écrans de jeu, sur ton truc? Si non, je ne vois pas d'argument valide dans ce que tu racontes là. Rien n'empêche de garder commun ce qui est commun et de stocker le spécifique à coté.
 

 
Ouais, puis tant qu'à faire autant avoir une seule table avec un id et un champ json et basta, c'est plus facile à migrer.
 
On n'est absolument plus dans ce que j'appelle une base de données, là, limite le SGBD sert juste à indexer des fichiers plats....j'imagine la gueule des collègues qui doivent faire du décisionnel le jour où je leur amène une base de ce genre...
Bref, chacun fait comme ça l'arrange, au final...mais de mon expérience, et surtout sur des applis purement de gestion comme celle qui a démarré cette discussion, les données et leur bonne modélisation SONT l'application, et prendre des raccourcis qui font gagner 2h de dev parce-que c'est pratique sur le moment se paye souvent bien plus cher à l'arrivée. Je suis de l'école qui pense que l'applicatif n'est qu'un moyen de présenter et d'interagir avec les données, et que détériorer le modèle de données pour accommoder l'applicatif est une hérésie...mais c'est un point de vue qui semble perdre en popularité ces dernières années.

T'es si vieux que ça pour vouloir te faire chier au taff pour du confort ?

"e que s'apelerio MongoDB"

Au niveau intérêt des projets, il n'y a pas de raison que ça soit moins bien (ni mieux) que maintenant.
A côté, par contre...
Et ouais, je suis vieux

T'es souvent confronté aux à-côté ?
T'es vieux comme Harko ?