Une table mysql avec de nombreux champs ou plusieurs (centaines de) tables avec moins de champs?

Question

Je suis en train de concevoir un système pour un client, où il est capable de créer des formulaires de données pour différents produits qu'il vend lui-même. Le nombre de champs qu'il utilisera ne dépassera pas 600-700 (scénario le plus défavorable). Comme il semble qu'il sera probablement dans la gamme de 400 - 500 (max).

j'avais 2 méthodes à l'esprit pour créer la base de données (à l'aide des métadonnées):

a) Créer une table pour chaque produit qui contiendra uniquement les champs nécessaires pour ce produit, ce qui entraînera des centaines de tables mais avec seulement les champs neccessary pour chaque produit

ou

b) utiliser une table unique avec tous les champs de formulaire availabe (toute plage, résultant en une table à partir de 300 courant à max 700) qui ont des champs MANY, dont seulement environ 10% seront utilisés pour chaque entrée de produit (un produit ne devrait normalement pas utiliser plus de 50-80 champs)

Quelle est la meilleure solution? En gardant à l'esprit que la maintenance de la table (création, mises à jour et changements) à la table (s) sera faite en utilisant des métadonnées, je n'aurai pas besoin de faire des changements à la table (s) manuellement.

Merci!

/**** ***** MISE A JOUR/

Juste une mise à jour, même après cette longue période (et allot d'expérience supplémentaires recueillies) que je devais mentionner que pas normalizing votre base de données est un terrible idée. Qui plus est, une base de données non normalisée presque toujours (tout simplement d'après mon expérience) indique également une conception d'application erronée.

Answer 1

Votre facteur déterminant est de savoir si normalization est requis. Même si vous ajoutez uniquement des données à l'aide d'une application, vous devez toujours prendre en compte les anomalies, par ex. Que se passe-t-il si le numéro de téléphone de quelqu'un change et qu'il insère plusieurs lignes pendant la durée de vie de l'application? Quelle rangée contient le bon numéro de téléphone? Par exemple, vous trouverez peut-être repeating groups dans vos données, comme une personne avec plusieurs numéros de téléphone; plutôt que d'avoir trois colonnes appelées "Phone1", "Phone2", "Phone3", vous casseriez ces données dans sa propre table.

Il existe d'autres problèmes de normalisation, tels que les dépendances transitives ou non-clés. Ces concepts vous mèneront probablement à une conception de table de base de données sans modification anomalies, comme vous devriez l'espérer pour!

Answer 2

j'aurais 3 tables:

• produit

  • id
  • nom
  • tout ce dont vous avez besoin

• champ

  • id
  • nom du champ
  • tout ce que vous pourriez avoir besoin

• product_field

  • id
  • Product_ID
  • field_id
  • valeur champ

Answer 3

Pulegiums solution est une bonne façon d'aller.

Vous ne souhaitez pas utiliser la solution one-table-for-product-product, car la structure de votre base de données ne doit pas être modifiée lorsque vous insérez ou supprimez un produit. Seules les lignes d'une ou de plusieurs tables doivent être insérées ou supprimées, pas les tables elles-mêmes.

Answer 4

Bien qu'il soit possible que cela soit nécessaire, avoir autant de champs pour quelque chose d'aussi simple qu'une liste de produits m'a l'air d'avoir un design imparfait. Vous devez analyser vos structures de table potentielles pour vous assurer que chaque champ ne contient pas plus d'une information (par exemple, "2 marteaux, 500 clous" dans un seul champ est mauvais) et que chaque information n'a pas plus d'un champ où il appartient (par exemple, ayant phone1, phone2, phone3 champs est mauvais). L'une ou l'autre de ces situations indique que vous devez déplacer cette information dans une table liée distincte avec une clé étrangère reliant à la table d'origine. Comme l'a démontré pulegium, cette technique peut rapidement faire tomber les choses à trois tables avec seulement une douzaine de champs au total.