J'ai un petit problème en essayant de décider du schéma de la base de données pour un projet en cours. Je ne suis en aucun cas un DBA.SQL Design Question concernant le schéma et si la paire valeur nom est la meilleure solution
L'application analyse un fichier en fonction de l'entrée de l'utilisateur et entre ces données dans la base de données. Le nombre de champs pouvant être analysés est compris entre 1 et 42 au moment actuel.
La conception actuelle de la base de données est entièrement plate avec 42 colonnes; certains ont répété des colonnes telles que address1, address2, address3, etc ...
Cela dit que je devrais normaliser les données. Cependant, l'intégrité des données n'est pas nécessaire en ce moment et la façon dont les données sont façonnées, je regarde plusieurs jointures. Ce n'est pas une mauvaise chose, mais les données sont toujours dans une relation 1 à 1 et je vois encore beaucoup de champs vides par rangée. Donc, je crains que cela ne permette pas à la base de données ou à l'application d'être très extensible. S'ils veulent ajouter plus de champs à analyser (ce qu'ils font) que je n'aurais besoin de créer une autre table et d'ajouter une autre clé étrangère à la table de liaison.
La troisième option est que j'ai une table où les champs sont définis et une table pour chaque enregistrement. Donc ce que je pensais est de faire une table qui stocke la valeur, puis des liens vers ces deux tables. Le problème est que je peux imaginer la taille de cette table grandissant en fonction de la taille de l'entrée. Si quelqu'un me donne un fichier avec 300 000 enregistrements de 300 000 x 40 = 12 millions, j'ai donc quelques réserves. Cependant je pense que si j'arrive à ce point que je devrais être heureux il est utilisé. Cette option permet également un affichage plus personnalisé des informations, même si un peu plus de travail, mais peu retravailler, même si vous ajoutez plus de champs. Le problème se résume donc à: 1. La conception actuelle est un fichier plat qui rend l'extension difficile et n'est pas normalisée. 2. Normaliser les tables mais pas de réels avantages pour le moment mais les exigences changent. 3. Normalisez-le dans la paire valeur nominale et espérez que la taille ne nuise pas.
Il existe un grand nombre d'insertions, de mises à jour et de sélections par rapport à cette table. Donc la performance est un souci mais je crois que le dicton est design maintenant, test de performance plus tard?
Je manque probablement quelque chose de pratique, donc tout commentaire serait apprécié, même s'il s'agit d'une vérification rapide.
Nous vous remercions de votre temps.
Merci pour la réponse. Après avoir effectué quelques tests, il semble que la conception de paire nom-valeur fonctionne très bien sur les grands ensembles mais semble ralentir sur les instructions plus petites en raison de quelques jointures de plus. Même en ajoutant des index, je ne peux toujours pas me rapprocher car j'ai 4 secondes pour la table dénormalisée et 20 secondes pour la paire valeur nom. En fin de compte juste besoin d'aller de l'avant et de l'extraire assez loin où cela peut être changé si besoin est. – Aur