une table de base de données doit avoir des valeurs par défaut?

Question

Je discutais avec un développeur au travail sur la question des cas où une utilisation de la table des valeurs par défaut. Y at-il une règle dure et rapide à ce sujet ou est-il une zone grise dans les meilleures pratiques?

Answer 1

Ma règle: si plusieurs enregistrements utiliseront cette valeur par défaut (au moins au début) j'aime l'utiliser comme un défaut. Par exemple, une table d'image pour les produits dans un magasin en ligne peut avoir un chemin par défaut de images/NoPictureYet.png. Finalement, ceux qui seront remplacés obtenir, mais pour des charges de traitement par lots de données où les images n'existent tout simplement pas encore (et peut-être la plupart d'entre eux ne le sera jamais!), Un défaut est logique (pour moi, au moins).

S'il n'y a pas défaut sensible (comme « prénom » dans une base de données clients - Je ne veux pas que mon nom par défaut à « FirstName »), je fais non annulable et non par défaut - c'est la responsabilité de l'application pour assurer qu'une valeur correcte s'entrée.

Mais aucune règle dure et rapide à ce sujet. Tout varie un peu;)

Answer 2

Un cas pratique où j'ai personnellement trouvé un bon usage des valeurs par défaut est une colonne de last_modified.

Cette colonne est jamais mis à jour par des procédures stockées ou la logique métier, mais est mis à jour automatiquement par les déclencheurs lorsque toute valeur dans la ligne change. Cependant, il est également mis à GETDATE() par défaut de sorte que la valeur d'une nouvelle ligne contiendrait l'horodatage de sa création, ce qui est essentiellement quand la dernière modification.

ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
                  DEFAULT GETDATE()
                  FOR last_modified;

Le déclencheur de mise à jour alors ressembler à quelque chose comme ceci:

CREATE TRIGGER trigUpdate_users 
ON users 
FOR UPDATE 
AS 
BEGIN 
    IF NOT UPDATE(last_modified) 
        UPDATE users SET last_modified = GETDATE() 
        WHERE user_id IN (SELECT user_id FROM inserted);
END 
GO

Answer 3

Aucune règle stricte et rapide peut être appliqué. Cela dépend des colonnes. Il peut être tout à fait raisonnable d'avoir un type de commande par défaut, par exemple, mais l'idée d'un défaut pour un numéro de téléphone du client n'a pas de sens.

Answer 4

Je dirais que son une zone grise. En général, je ne concevoir une nouvelle base de données avec beaucoup de valeurs par défaut, mais vous devez souvent les utiliser pour améliorer un système existant.

Par exemple l'ajout d'une nouvelle colonne non nulle à une base de données existante. Vous voudrez peut-être pas (ou être en mesure de) mettre à jour tout le code qui insère dans cette table, vous devrez mettre un défaut pour faire en sorte que tout code « héritage » peut encore insérer des données (en supposant que la valeur par défaut est appropriée pour le code existant bien sûr).

Answer 5

Les valeurs par défaut sont importantes si la colonne doit avoir une valeur (il est non nulle). En fait, si vous changez une colonne de permettant de ne pas les valeurs NULL permettant une valeur par défaut est à peu près nécessaire pour ne pas tout le code existant peut remplir une valeur. Parfois, dans ce cas, la valeur par défaut est quelque chose comme « inconnu ». Cela est particulièrement vrai si vous voulez utiliser les valeurs avec pour fournir les valeurs par défaut aux enregistrements exisiting où le champ est nul dans l'instruction ALTER TABLE qui change la colonne NOT NULL

Les valeurs par défaut sont critiques pour les champs que l'interface utilisateur ne traite pas habituellement. Par exemple, nous avons des valeurs par défaut sur les colonnes date_inserted et user_inserted que l'utilisateur ne connaît même sont là. Cela est particulièrement important si de nombreuses applications différentes peuvent remplir les données pour assurer que personne n'oublie ces colonnes.

Ensuite, il y a des colonnes qui sont généralement donnés une valeur sur la saisie des données qui peuvent changer par la suite. Des choses comme une colonne d'état.

De nombreuses colonnes ne peuvent pas avoir vraiment un défaut bien. Quel serait l'adresse par défaut ou le nom d'un utilisateur?

Answer 6

tl; dr: Les valeurs par défaut sont la logique métier, et je veux la logique métier dans le modèle d'objet. En tant que tel, une base de données ne peut pas contenir des valeurs par défaut.

par exemple. Dans la base de données que j'ai un champ de bits: IsANicePerson. Ce champ se traduit par une propriété sur la classe Person. Être optimiste par nature, je veux la valeur par défaut de cette propriété pour être « vrai ». Ainsi, dans la classe Person je mets en œuvre cette (comme la valeur par défaut du champ de support de isANicePerson). Si je permettrais les valeurs par défaut dans la base de données que je dois reproduire cette logique. Code double / logique est mauvais. D'où mon objection à leurs valeurs par défaut.

Disclaimer:. Je vis dans un OO monde et utiliser Linq2Sql

Answer 7

Il devrait être assez simple. Si les données doivent généralement être unique pour chaque ligne comme le numéro de téléphone du client ou de la valeur par défaut le changement le plus probable au fil du temps alors je ne l'utiliser. Cela signifie qu'il est vraiment utile pour remplir CreateDate, ModifiedDate, ou d'autres colonnes de cette nature.

Answer 8

Voici les directives que j'utilise personnellement en ce qui concerne les valeurs par défaut qui me ont bien servi dans le passé. Dans les exemples suivants, envisager une base de données back-end avec plusieurs applications avec accès en lecture / écriture à l'arrière-plan. Dans ces cas, il est essentiel que la base de données définissent la manière dont les données doivent modéliser et donc assurer l'intégrité des données.

1) et des colonnes CreatedDate ModifiedDate. Ces colonnes auront typiquement getdate () (serveur SQL) défini comme la valeur par défaut. Comme mentionné dans d'autres postes, ces champs peuvent ensuite être mis à jour avec des déclencheurs etc.

2) colonnes d'état booléennes. Exemples: "IsDefault", "IsDeleted" (pour l'audit), "IsActive", etc. Tous ces champs auront généralement un état par défaut logique qui doit être défini par le modèle de données. Les exceptions à ce serait évidemment nullables champs booléens tri-état où l'état nul représente quelque chose sur les données stockées dans le dossier.

3) définitions de contraintes de données: Les colonnes avec AllowNull = false et aucun défaut défini. En d'autres termes, une valeur est requise par l'application.

4) table de recherche des identités clés étrangères: Ceci est probablement pas la norme, mais pour beaucoup de clés étrangères de table de recherche je définirai un défaut qui couvre l'état initial d'un enregistrement. Ainsi, par exemple, dans une table « Evénement » la colonne de clé étrangère « EventTypeId » (int-autoincrement) aura par défaut 1 et représenter « Général » ou quelque chose. Cela couvrira la plupart des scénarios où, par exemple, je veux enregistrer un événement mais ne se soucient un identifiant de type spécifique.

5) colonnes de chaîne non critiques: « Description », « Commentaire », etc. Pour ces colonnes, je définirai généralement « » comme valeur par défaut uniquement à simpify System.DBNull => conversion Null manipulation dans les applications. C'est quelque chose qui ne peut pas être applicable dans tous les scénarios en particulier lorsque la table concernée contient des millions de lignes et de l'espace de stockage est un problème.

Donc, en résumé, utilisez les valeurs par défaut pour assurer l'intégrité des données des données réelles stockées dans la base de données. Le modèle de données devrait définir ces règles d'intégrité des données à l'intérieur lui-même et toute application en interaction avec elle sera et devrait être obligé de respecter ces règles. S'il vous plaît noter également que ce n'est pas la doctrine et qu'il y aura toujours des exceptions. Considérez chaque scénario individuellement pour que il est logique de votre base de données / application.

Answer 9

Certainement une zone grise. Il est classique combien la logique métier de mettre en question la base de données.

Si nous voulions être puriste et dire non logique métier appartient à la base de données, la réponse ne serait jamais les utiliser.

Être pratique, nous pouvons faire une exception comme nous le faisons souvent et permettre à la logique d'un défaut dans la base de données.