J'ai récemment pris en charge le développement sur une base de données SQL Server 2000 qui a besoin d'aide. Nous prévoyons de le mettre à niveau vers SQL Server 2005 bientôt. Cette base de données n'a pas de champs d'audit sur les tables (CreatedBy, CreatedDate, etc.), pas de clés étrangères, et une conception globale terrible. Il y a une demi-douzaine de programmes qui accèdent directement à la base de données en utilisant SQL inline, et d'autres pratiques anciennes/mauvaises. Je souhaite nettoyer le schéma et l'accès aux données. Avez-vous des suggestions pour un bon endroit pour commencer? C'est une base de données de production, et elle doit continuer à fonctionner pendant qu'elle est améliorée. Merci.Meilleure approche pour le développement de base de données Brownfield dans SQL Server 2000/2005
Répondre
Vous allez probablement devoir commencer par les applications qui accèdent à la base de données. Il est plus que probable que vous constaterez que toute modification du schéma de base de données viendra casser ces autres applications. Le coupable le plus commun que j'ai trouvé est select * sql suivi de l'accès aux données basées sur la position de la colonne. Si vous insérez une colonne avant la dernière colonne, ce code sera rompu. De même, à moins d'utiliser des valeurs par défaut pour vos nouvelles colonnes, toute commande d'insertion échouera. Le mieux est de comprendre comment ces programmes externes utilisent la base de données, puis de concevoir une nouvelle base de données, puis de migrer chacun de ces programmes dans la nouvelle base de données, un à la fois.
Une modification apportée à cette base de données pendant qu'elle est en production est presque garantie pour briser les autres applications.
Vous pouvez peut-être corriger, analyser, normaliser etc. le schéma tout en conservant le schéma/interface actuel derrière les vues. L'utilisation d'un déclencheur avant sur les vues permet aux applications d'écrire et de lire comme elles le souhaitent. De cette façon, vous pouvez commencer à migrer les applications clientes vers un nouveau schéma tout en permettant à l'application en cours de fonctionner. Et vos données sont plus sûres (DRI, FK, DF, CK, etc.) dans son nouveau schéma. Cela maintient également le contrat d'interface cohérent pour cette feuille de calcul inattendue qui s'exécute une fois par mois et personne ne le sait est essentiel pour ce rapport de fin de mois.