Conception de la base de données concernant les entrées dynamiques - Une ligne ou plusieurs lignes?

Question

J'ai essayé de concevoir un schéma de base de données pour un projet parallèle, mais je n'ai pas été en mesure de produire quelque chose avec lequel je suis à l'aise. J'utilise ASP.Net avec LINQ pour mon accès aux données:

Je vais autoriser les utilisateurs à spécifier jusqu'à 10 "articles". chacun avec 2 propriétés numériques et 1 propriété de référence, le nom de l'élément.

Si je mettais cette entrée sur une ligne, elle équivaudrait facilement à plus de 30 colonnes (minimum), par exemple. item_1_name (ref) item_1_weight item_1_volume item_2_name ... etc ...

Et je ne peux pas simplement transformer ces colonnes en tables référentielles car chaque propriété peut aller de 1 à 400 +.

J'ai également pensé que si un utilisateur décidait de ne mettre qu'un élément dans son entrée, la méthode de création de l'objet pour ces données serait statique, comme avec LINQ, il faudrait que je vérifie si les propriétés et ce qui ne sont pas nuls. et travailler en conséquence. De plus, si je voulais augmenter le nombre d'éléments autorisés dans une entrée, ce serait un casse-tête de travailler avec.

L’autre option à laquelle j’ai pensé est simplement de créer une ligne pour chaque élément et de l’attacher à un ID d’entrée. Je n'aurais donc pratiquement jamais d'entrées nulles, mais ma table aurait une profondeur astronomique, mais pas très large, car il n'y aurait que 5 colonnes impaires.

Y-a-t-il quelque chose que je néglige dans ma conception / existe-t-il un moyen beaucoup plus efficace et efficace de le faire?

EDIT: Quand je dis que cela va se développer de manière astronomique, je le pense en ce sens: un utilisateur peut créer une entrée et chaque entrée aura très probablement un groupe d’articles. Donc, disons qu'ils font 1 entrée par jour sur le site, ils pourraient avoir 3 groupes d'éléments, avec le nombre maximal d'éléments (10), ce qui équivaudrait à 30 éléments pour cette entrée unique. Effectuez une entrée chaque jour pendant une semaine à ce rythme et vous pourriez avoir 210 lignes pour cet utilisateur unique.

Answer 1

Je vous recommande le dernier modèle que vous mentionnez, créez un tableau dépendant avec cinq colonnes:

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

Je montre un tableau num_items ci-dessus, qui contient les nombres de 1 à 10 si vous souhaitez limiter les utilisateurs à 10 éléments au plus:

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

L'avantage de cette conception est qu'il est facile de COUNT () combien d'éléments a un utilisateur donné, il est facile de calculer des choses comme MIN () et MAX () pour une propriété donnée, vous pouvez appliquer une clé étrangère à la propriété référentielle, etc.

Certaines bases de données disposent d'une fonctionnalité permettant de déclarer la seconde partie d'une clé primaire composée ( item_id dans ce cas) comme auto-incrémentée. Ainsi, si vous spécifiez la valeur pour entity_id mais en omettant item_id , il obtient automatiquement la prochaine valeur inutilisée (mais ne comble pas les espaces vides si vous en supprimez une). Vous ne précisez pas quelle marque de base de données vous utilisez, je vous laisse donc découvrir cette fonctionnalité.

modifier: Comme le dit Tony Andrews dans sa réponse, le nombre de lignes ne pose pas de problème. Vous ne précisez pas quelle marque de base de données vous souhaitez utiliser, mais vous pouvez compter sur la base de données pour traiter facilement des millions de lignes, à moins de choisir un produit particulièrement faible comme MS Access. Si vous choisissez bien les index et écrivez des requêtes utilisant ces index, l'efficacité ne devrait pas être un problème.

Answer 2

utilisez une seule table d'éléments:

userId, itemIndex, isReference, numericValue, referenceValue

Ainsi, la valeur de item_3_name pour l'utilisateur 999 est traduite en

999,3, true, null, valeur

Vous devrez vous-même appliquer certaines contraintes, par exemple. le nombre maximal d'éléments par utilisateur, etc.

Answer 3

Une base de données appropriée consisterait à stocker chaque utilisateur / élément sur une ligne distincte. Cela sera beaucoup plus facile à utiliser et supprimera la restriction arbitraire de 10 éléments. Je ne dirais pas que cela poussera "de manière astronomique", il y aura environ 10 rangées (nombre d'utilisateurs).