Base de données Modification ou recommencer?

Question

Je travaille actuellement sur la reconstruction d'un site web existant qui est utilisé en interne dans ma société pour la gestion de projet, c'est un utilitaire de suivi de bogues qui intègre des opérations de comptabilité et de support client. Actuellement, le modèle de base de données est très répétitif. Un UserId est actuellement lié à un enregistrement (relation FK dans une table utilisateur contenant toutes les informations sur l'utilisateur), puis toutes les informations sur le l'utilisateur existe également dans la table.

J'ai été chargé d'améliorer le site Web et la fonctionnalité du modèle; cependant, je veux réduire la répétition des données dans le site Web (est-ce la normalisation ou est-ce la séparation des éléments non reliés dans des tables séparées?). Je ne suis pas sûr de la meilleure façon de procéder. Je pense à générer les scripts de création pour la base de données et à créer un nouveau projet de base de données dans VS pour ensuite modifier la base de données, puis générer des scripts pour remplir le nouveau modèle de base de données à partir de l'ancienne base de données.

Je prévois d'utiliser Entity Framework et ASP. NET MVC 2 pour construire le site Web car je pense qu'il fournit le modèle le plus flexible aller de l'avant pour la modification et la maintenance du site. La raison pour laquelle je pose cette question est parce que je suis très familier avec l'utilisation des bases de données et la modification des bases de données existantes pour les applications et les sites Web, mais j'essaie de trouver la meilleure façon d'en créer une.

Je suis curieux de savoir s'il y a du matériel sur la meilleure façon de le faire ou si je devrais utiliser un outil différent pour le faire?

Edit: Fournir plus d'informations sur le modèle

Il y a 4 grands domaines que nous avons qui sont utilisés:

1. Cases (bogues, dispositifs, tâches de travail, etc.) 2. Tickets (Tech Support Events)
2. Erreurs (Erreurs générées à partir de notre bibliothèque de journalisation, Fondamentalement une trace de pile avec des informations client)
3. Licence (Conserve une trace de chaque coutume ers Licence permet de modifier ces licences)

Ce sont les objets qui sont mélangés et utilisés dans les 4 domaines principaux ci-dessus.

1. Utilisateurs (Les personnes qui utilisent le système)
2. clients (personnes qui utilisent notre logiciel)
3. Stores (endroits où nos clients utilisent nos logiciels)
4. Produits (Notre logiciel)

Relations

Cas: Un cas doit avoir un utilisateur, peut avoir un client, magasin, erreur, Billets et/ou produit

Billets Un billet doit avoir un utilisateur et un client, peut avoir un magasin, erreur et/ou Produit

Erreurs: Une erreur doit avoir un produit, peut-il avoir un cas, billets, magasin et/ou produit

licences: a licences doit avoir un produit et le client, peut avoir un magasin

Comme je l'ai dit site très basique, avec une base de données pas super complexe, si fait correctement.

Actuellement, la base de données n'a pas de contraintes FK, la réplication de beaucoup d'informations dans chaque table et beaucoup de tables supplémentaires qui sont dupliquées avec des noms différents.

E.g.

Chaque type de cas possède une table distincte, de sorte qu'il existe une table FeatureRequest, Bug, Tasks, Completed, etc. qui contiennent toutes les mêmes informations.

Answer 1

La normalisation consiste à stocker des données sans redondance ni anomalies.

Un exemple d'anomalie peut être lorsque les attributs d'un utilisateur de votre table principale ne sont pas synchronisés avec la table des utilisateurs. Quelqu'un modifie les informations sur cet utilisateur dans une table sans refléter les changements dans la copie redondante. Le problème est qu'il est difficile de savoir quel changement est le bon. Certaines personnes pensent que la normalisation consiste simplement à diviser les tables en tables plus petites, car c'est ce qu'elles considèrent comme le type de changement le plus courant. Mais ce n'est pas le but de la normalisation. C'est juste par hasard que la plupart des erreurs de non-normalisation impliquent de bourrer trop de données dans une table où plusieurs tables seraient correctes.

Il est difficile de répondre à votre question sur la modification de votre base de données ou sur la création d'une nouvelle base de données et la migration vers celle-ci.

Ce que je ferais dans votre cas est de concevoir une base de données correctement normalisée, puis d'examiner les différences entre celle-ci et votre base de données existante. Imaginez ce que vous auriez à faire pour chaque différence, pour remplacer votre ancienne base de données par la nouvelle, par opposition à une migration de données. Il se peut que seules quelques modifications soient nécessaires, ne laissant que les colonnes redondantes. Ou il se pourrait que d'importantes modifications soient nécessaires. Il est impossible de dire jusqu'à ce que vous fassiez le travail de création d'un modèle de données normalisé afin que vous puissiez comparer.

La plus grande tâche pourrait être d'adapter votre code d'application qui utilise la base de données. Un moyen de faciliter cette transition consiste à créer des vues de base de données au-dessus de la base de données normalisée, qui imitent votre ancienne base de données non normalisée. De cette façon, nous espérons ne pas avoir à réécrire chaque bit dans votre application en une seule fois, vous pouvez garder une partie de la même chose au moins jusqu'à ce que vous puissiez refactoriser le code. Il est également idéal d'avoir un bon ensemble de tests de régression en place. Ainsi, vous pouvez être sûr que votre application effectue toutes les tâches qu'elle est supposée faire, en retravaillant la base de données et le code qui utilise la base de données.

---

Re votre commentaire: Vous mentionnez que vous ajoutez de nouvelles fonctionnalités au modèle utilisateur en même temps. Je trouverais cela trop confus pour essayer de le faire simultanément avec le refactoring. Le refactoring ne change généralement pas la fonctionnalité, il ne change que l'implémentation. Mais le refactoring ajoute de la valeur, car il facilite la maintenance ou le débogage du code, améliore l'efficacité ou vous prépare à modifier plus facilement les fonctionnalités futures.

Je vous recommande de mordre la puce et d'ajouter vos nouvelles fonctionnalités de modèle utilisateur à l'ancienne base de données non normalisée. Il est bon de tirer parti des nouvelles fonctionnalités à court terme, et vous devez d'abord développer ces fonctionnalités pour les comprendre suffisamment pour les prendre en compte dans votre grand projet de refactoring.

---

Voici quelques suggestions de ressources pour vous aider à comprendre vraiment ce que signifie la normalisation:

• SQL and Relational Theory par CJ Date de
• A Simple Guide to Five Normal Forms in Relational Database Theory par William Kent
• Database Normalization à Wikipédia et ses sous-pages par moi, Bill Karwin. J'ai écrit un chapitre sur la normalisation de la base de données qui, je l'espère, l'explique en anglais et avec de bons exemples.

Voici quelques ressources pour gérer les changements à une base de données:

• Refactoring Databases par Scott W. Ambler et Pramodkumar J. Sadalage
• Agile Database Techniques: Effective Strategies for the Agile Software Developer par Scott W. Ambler

Answer 2

Combien de temps avez-vous, et quelle est la taille de la base de données?

Il est très difficile de répondre à cette question en noir et blanc sans être immergé dans votre environnement et votre business case. Il ne semble pas que votre limite soit technologique, juste pour choisir entre des solutions.

Recréer est ce que les programmeurs recherchent instinctivement. Cependant, dans le «monde réel», nous consacrons parfois beaucoup d'efforts à quelque chose qui n'est pas utilisé ou qui ne durera pas longtemps.

Donc, de la nourriture pour la pensée. Combien de temps cela vous prendra-t-il pour refaire la base de données, combien cela coûtera-t-il? Travailler avec ce qui existe suffira-t-il pour la fonctionnalité demandée?