Bonjour,

J'ai une question de conception: dans une application, comment faire pour que l'utilisateur puisse créer ses propres types de données sans avoir recours à la maintenance d'un développeur ?

Ex: Le site d'un vendeur de tapis souhaite mettre en vente des nouveaux tapis spéciaux qui nécessitent + d'informations pour être décris, le format initial de données ne contenant que les dimensions, matériaux et origine. Il souhaite par exemple enregistrer le poids pour ces tapis là.

Ma solution naïve serait de factoriser les informations essentielles dans une table de la BDDR et permettre à l'utilisateur de créer des nouvelles tables (avec une interface simplifiée il ne va évidemment pas écrire une requete sql), sur lesquelles il va ajouter les informations qu'il souhaite, ces tables hériteront de la table mère, mais je n'ai jamais entendu parler de cette méthode l'an dernier durant mes cours donc je sais pas si ça se fait.

Quel langage ? Quel framework ?

J'imagine que ça peut très bien se faire avec un backoffice (comme celui de Drupal) ou... un PIM.

J'ai pas encore decidé de ça, ce sera soit node/angular ou bien php/mysql avec du js et bootstrap. L'application va être simple (3-4 pages maximum).

Tu dois mieux penser ta structure de donnée, tu dois pouvoir gérer ta création de produit sans créer de table à la volé.

Le but c'est simplement de créer des lignes dans des tables existantes

c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

Le 06 novembre 2019 à 11:24:29 UndeadMarston6 a écrit :
Tu dois mieux penser ta structure de donnée, tu dois pouvoir gérer ta création de produit sans créer de table à la volé.

Le but c'est simplement de créer des lignes dans des tables existantes

Je suis d'accord avec ça.
Créer une table, c'est un gros non pour moi.

Par contre, tu pourrais utiliser MongoDB par exemple, qui te permet de stocker des dictionnaires. ça rendrait la gestion de ton stockage de données extrêmement simple.

Tu pourrais donc stocker ton objet1 en tant que :
{"prix": 22,
"poid": 1}
Et ton objet deux en tant que :
{"prix": 22,
"poid": 1,
"largeur": 3}

Tu pourrais sinon sérialiser tes objets dans une bdd SQL (attention avec ça, faut savoir ce qu'on fait quand on décide d'implémenter de la sérialisation)

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est la solution que je conseille parce que ça permet de faire des queries correctes sur les propriétés.

Le 06 novembre 2019 à 16:13:34 Batora a écrit :

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est la solution que je conseille parce que ça permet de faire des queries correctes sur les propriétés.

On peut le faire avec MongoDB aussi.

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est la bonne solution, je boss sur un projet où ils ont mis en place ce genre d'infos, ils en ont crée de plusieurs type qui permet de définir si c'est une saisie libre, une dropdown, un nombre ....

En tout cas je partirai sur ça, juste après à toi de récupérer ça sous forme de liste ou de dictionnaire clé valeur, certes c'est le fonctionnement classique de certaine base NoSQL mais ça n'a aucun sens de passer sur du NoSQL juste pour ça.

Le 06 novembre 2019 à 18:20:17 Raidden36 a écrit :

Le 06 novembre 2019 à 16:13:34 Batora a écrit :

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est la solution que je conseille parce que ça permet de faire des queries correctes sur les propriétés.

On peut le faire avec MongoDB aussi.

Ce serait con de passer sur Mongo juste pour ca.

Bonjour, j'ai pris notes de vos réponses et vous en remercie ! Du coup je vais partir sur la solution de mov_eax_1.

Un doute subsiste, si l'on veut classifier les produits en plusieurs type (ex: Un jour notre vendeur souhaite vendre du parquet en plus des tapis) afin de créer des types génériques, cela doit aussi se faire via la table propriété (via un attribut que l'on nommerait "type" ?)

EDIT: Je vais mettre le type dans la table "article" et m'assurer que chaque article du type X soit bien référencé par toute les propriétés en question

Le 06 novembre 2019 à 22:26:38 NurseryRhyme a écrit :

Le 06 novembre 2019 à 18:20:17 Raidden36 a écrit :

Le 06 novembre 2019 à 16:13:34 Batora a écrit :

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est la solution que je conseille parce que ça permet de faire des queries correctes sur les propriétés.

On peut le faire avec MongoDB aussi.

Ce serait con de passer sur Mongo juste pour ca.

Si j'ai bien compris, il était en recherche de techno, donc à mon sens, pour une petite marketplace, on ne touche pas aux problèmes de mongo, donc il est plus adapté que mySQL.
Mais ce n'est que mon avis.

Le 06 novembre 2019 à 11:42:32 mov_eax_1 a écrit :
c'est pas un soucis tu peux avoir une table qui représente un article et une table qui représente une propriété
quand le vendeur crée son article, il peut rajouter autant de propriétés qu'il veut

|article| 1,n ------------ 1,1 |propriete| 

C'est ce que fait WordPress il me semble ... Je ne suis pas vraiment fan.

Je trouve la solution mongoDB plus intéressante

Et même je dirai d'utiliser PostgreSQL, tu peux stocker toute en JSON dans un champ et faire des queries dans le JSON même (Postgre )

Je connais pas trop MongoDB ni le Nosql en général, je sais pas si ça prendrait du temps de me former la dessus sachant que j'ai des délais à respecter (même si la partie conception de la BDD ne devrait pas être trop longue)

Mais c'est quoi cette génération abreuver au JSON, qui veut directement stocker du JSON en BDD et le NoSQL n'est pas la réponse à tout, dans son cas un sgbdr classique est suffisant (mysql/postgrey/oracle/sql server ...).
Il suffit juste de savoir comment conceptualiser les données, à force de pratique ça te paraîtrai simple.
Je te conseil dans ton cas d'avoir une table ou tu stock les types d'articles et qui soit modifiable par l'utilisateur pour ajouter de nouveau type d'articles, une autre table ou tu défini des paramètres supplémentaire pour un article (tu peux sinon réutiliser la première table), ta table article ou tu stock ton article avec une foreign key vers la table type article et une dernière table qui fait le lien entre un article et la liste de ses propriétés ...

Je pense avoir à peu prés fait ça (table "type", table "propriete", table "valeur" et la table "article"):

Chaque article référencie son type
Chaque propriété référencie le type auquel elle est rattachée
Chaque valeur référenciee la propriété qu'elle mesure et l'article concerné

Mais c'est quoi cette génération abreuver au JSON

Le JSON est puissant et en utilisant les bons outils peut être traiter comme des champs (avec Postgre par exemple) donc c'est une excellente alternative

et une dernière table qui fait le lien entre un article et la liste de ses propriétés ..

Ce que fait WP en gros, je pense qu'il faut savoir utiliser les bons outils au bon moment personnellement mais bon

Le 07 novembre 2019 à 10:19:37 boucif a écrit :
Mais c'est quoi cette génération abreuver au JSON, qui veut directement stocker du JSON en BDD et le NoSQL n'est pas la réponse à tout, dans son cas un sgbdr classique est suffisant (mysql/postgrey/oracle/sql server ...).
Il suffit juste de savoir comment conceptualiser les données, à force de pratique ça te paraîtrai simple.
Je te conseil dans ton cas d'avoir une table ou tu stock les types d'articles et qui soit modifiable par l'utilisateur pour ajouter de nouveau type d'articles, une autre table ou tu défini des paramètres supplémentaire pour un article (tu peux sinon réutiliser la première table), ta table article ou tu stock ton article avec une foreign key vers la table type article et une dernière table qui fait le lien entre un article et la liste de ses propriétés ...

à l'origine je ne fais que du SQL, je me suis mis aux BDD qui stock en objet/JSON que récemment.
Et même si ça pose beaucoup de soucis dans certains cas, notamment lors de traitement big data où tu dois update de grosses BDD (Mongo, par exemple, fait un buffering assez sale des querys, et donc, va être de plus en plus en lent au fur et à mesure que tu le solicite, vu qu'il ne permet pas de faire des querys "intelligentes" comme en SQL), ça a aussi beaucoup d'avantages dans d'autres.
Ne pas s'adapter aux nouvelles technos, et refuser d'en tirer le bon où il est, c'est un problème, pour moi.

En l’occurrence, ici, on est pile dans ce pourquoi des BDD comme Mongo existent. C'est, dans ce cas là, je suis désolé, mais objectivement mieux.

En soit, tant que tu n'as pas à faire de query complexes, Mongo est mieux, car complètement implémenter dans la plupart des langages, pas de langage annexe.
C'est aussi bien son atout que son principale défaut.

Sur une marketplace comme celle là, ça m'étonnerait grandement qu'il y est à faire de query complexes (sur la majorité des marketplaces, c'est pas le cas), donc autant normaliser sa BDD.

Pour te répondre OP, Mongo est très facile à prendre en main, c'est comme si tu créais des objets dans ton code, et que tu les utilisais normalement.

Le 07 novembre 2019 à 10:30:40 Abdelmouloud3 a écrit :
Je pense avoir à peu prés fait ça (table "type", table "propriete", table "valeur" et la table "article"):

Chaque article référencie son type
Chaque propriété référencie le type auquel elle est rattachée
Chaque valeur référenciee la propriété qu'elle mesure et l'article concerné

Si tu fais une table propriete pas besoin de référencé un type ou tu peux mettre directement le nom de tes propriétés dans la table "type"

Bein c'est ce que fait Wp et plein d'autre outil je pense, j'ai du travailler sur 2-3 projets ou ce genre de chose est faite.

On va pas s'amuser à modifier la bdd à chaque fois que le client ajoute une propriété à ses données surtout que implique un redéploiement de l'application.
Passer par une relation ternaire est la meilleure solution