Je travaille avec une application d'entreprise et j'ai pris des conseils pour la conception de DB
lastchangedby , lastchanganedd , lastchangedpage
- Toutes vos procédures stockées qui ont dynamique SQL doivent avoir le paramètre @
BDebug . Par défaut, il est défini sur 0. S'il est défini sur 1, imprimez l'instruction SQL dynamique et cela sera vraiment utile dans le débogage.
- pour CRUD SPS, avez un moyen de mettre à jour partiellement la table. Si votre table dispose de 10 champs et de l'un des SP, vous vous souciez de mettre à jour seulement 5 champs, avez une couche d'abstraction pour le faire.
Tous les autres conseils utiles que vous pouvez penser?
EDIT: Merci pour toutes les réponses. Je cherche toujours une réponse qui peut fournir un lien vers des astuces / astuces / stratégies pour la conception de la DB.
6 Réponses :
À mon avis, il faudrait CreatedBy et
@RaFek - Dans notre application, nous stockons la création de créé comme étant le lastchangedby et même avec le champ créé également.
Ensuite, après la mise à jour de cet enregistrement, vous n'avez pas d'informations sur le créateur d'origine.
Pour # 1: Déplacement vers SQL Server 2008 et activez simplement la capture de données de modification. Si vous avez vraiment besoin de conserver des sentiers d'audit détaillés, cette fonctionnalité seul justifiera le coût.
Pour # 2: Toute procédure stockée avec Dynamic SQL devrait être automatiquement mise sur une double probation secrète (c'est-à-dire: elle est autorisée, mais doit passer par plusieurs niveaux d'examen de code pour s'assurer qu'il n'y a pas de meilleure façon de le faire).
En ce qui concerne la puissance du Web, il est préférable de ne jamais supprimer quoi que ce soit. Par conséquent, avoir une date de suppression que vous pouvez exclure ces objets qui ont été "supprimés" de vos recherches. Cela aide également les clients frénétiques qui ont subi accidentellement leur compte. Évidemment, cela ne devrait pas être utilisé dans chaque domaine.
Avoir une ignorance de ce champ de ligne sur des bases de données peut faciliter de nombreuses choses. J'ai trouvé que la plupart des solutions ont besoin d'un drapeau de style "ne pas utiliser à nouveau" de sorte que les anciennes données puissent être recherchées, mais de nouvelles entrées ne peuvent pas réutiliser l'ancien identifiant, etc.
Pour des raisons de performances, sur des plates-formes à grande échelle, vous voudrez peut-être prendre cela encore plus loin en mettant en œuvre la partition de table pour scinder vos données en direct et supprimer des données. Vous pouvez également envisager d'implémenter une base de données d'archives.
Quelques pensées qui se tient immédiatement à l'esprit lorsqu'ils travaillent avec une très grande base de données (VLDB):
Grandes tables de base de données, avec des millions d'enregistrements, peut bénéficier d'une partition de table.
Quelles sont mes tables les plus fréquemment consultées?
Considérez la séparation par FileGroup I.e. Placez la table client sur un groupe de fichiers et une table de transaction sur une autre. Cela permet à SQL Server de créer plusieurs threads pour l'accès au fichier créant la possibilité d'E / S séquentiel.
Ensuite, considérez ensuite la structure de disque physique sous-jacente, c'est-à-dire une LUN distincte pour chaque groupe de fichiers.
Vous aurez toujours déjà une stratégie d'indexation à l'esprit pour que les plates-formes VLDB devraient être fréquemment examinées. À mesure que les volumes de données augmentent et les modifications de la distribution des données pour que les plans d'exécution de vos requêtes d'accès aux données. Vous devriez planifier la nécessité d'examiner régulièrement votre stratégie d'indexation.
Les champs de LastChangedby, etc. Les champs sont assez inutiles. Si vous avez vraiment besoin d'une piste d'audit, vous avez besoin de tables d'audit séparées qui détachent les modifications et maintiennent une historique d'audit. Si vous n'avez pas besoin d'un sentier d'audit, les champs LastChangedby, etc. sont simplement ajoutés au travail sans valeur commerciale.
Les dates doivent être stockées au format UTC et converties en heure locale au client.