44 votes

Quelles sont les normes de base de données les plus utiles ?

J'ai quelques idées, certaines que j'ai accumulées au fil du temps, mais je veux vraiment savoir ce qui fait que les choses se passent bien pour vous lorsque vous modélisez une base de données :

  1. Le nom de la table correspond au nom de la clé primaire et à la clé de description
  2. Les schémas sont par domaine fonctionnel
  3. Évitez les clés primaires composites dans la mesure du possible (utilisez des contraintes uniques).
  4. Noms de tables et de champs en casse camel
  5. Ne pas préfixer les tables avec tbl_, ou les procs avec SP_ (pas de notation hongroise)
  6. Les bases de données OLTP doivent être au moins en BCNF / 4NF.

19voto

BenAlabaster Points 20189
  • Nommez des procédures stockées similaires avec le même préfixe, par exemple si vous avez 3 procédures stockées pour la personne. De cette façon, tout ce qui concerne la personne est regroupé en un seul endroit et vous pouvez les retrouver facilement sans avoir à parcourir toutes vos procédures pour les trouver.
    • PersonUpdate
    • PersonDelete
    • PersonCreate
  • Faites la même chose pour les tableaux lorsque vous avez des groupes de tableaux avec des données liées. Par exemple :
    • InvoiceHeaders
    • Lignes de facturation
    • InvoiceLineDetails
  • Si vous avez la possibilité d'utiliser des schémas dans votre base de données, utilisez-les. C'est beaucoup plus agréable à voir :
    • En-tête de la facture
    • Postes.de.ligne.de.la.facture
    • Détails.de.l'article.de.la.facture
    • Personne.Update
    • Personne.Supprimer
    • Personne.Créer
  • N'utilisez les déclencheurs que s'il n'y a pas d'autre approche raisonnable pour atteindre cet objectif.
  • Donnez aux noms des champs un préfixe significatif afin que vous puissiez savoir de quelle table ils proviennent sans que quelqu'un ait besoin de vous l'expliquer. Ainsi, lorsque vous voyez un nom de champ référencé, vous pouvez facilement savoir de quelle table il provient.
  • Utilisez des types de données cohérents pour les champs contenant des données similaires, c'est-à-dire ne stockez pas le numéro de téléphone en tant que numérique dans une table et en tant que varchar dans une autre. En fait, ne le stockez pas sous forme numérique, si je tombe sur un numéro de téléphone négatif, je serai furieux.
  • N'utilisez pas d'espaces ou d'autres caractères obscurs dans les noms de tables/champs. Ils doivent être entièrement alphanumériques - ou si j'avais le choix, entièrement alphabétiques à l'exception du trait de soulignement. Je travaille actuellement sur un système hérité où les noms de tables et de champs contiennent des espaces, des points d'interrogation et des points d'exclamation. Cela me donne quotidiennement envie de tuer le concepteur !
  • N'utilisez pas de mots-clés syntaxiques comme noms d'objets, cela vous causerait des maux de tête si vous essayiez d'en extraire des données. Je déteste être obligé d'écrire les noms d'objets sous la forme [index], cela fait deux caractères inutiles que je n'avais pas besoin de taper, bon sang !

13voto

HLGEM Points 54641

Une chose que je n'ai pas encore vue mentionnée :

N'utilisez jamais de mots-clés de la base de données comme noms d'objets. Vous ne voulez pas avoir à les qualifier à chaque fois que vous les utilisez.

Si vous faites une faute d'orthographe lors de la création, corrigez-la dès que vous la remarquez. Ne passez pas des années à devoir vous rappeler que dans cette table UserName est en réalité Usernmae. C'est beaucoup plus facile à corriger lorsqu'il n'y a pas beaucoup de code écrit à ce sujet.

N'utilisez jamais de jointures implicites (la syntaxe de la virgule), spécifiez toujours les jointures.

11voto

Raj More Points 22358

Rassembler les contributions de chacun dans une seule liste.

Normes de dénomination

  • Les schémas sont nommés par domaine fonctionnel (produits, commandes, expédition).

  • Pas de notation hongroise : Pas de noms de types dans les noms d'objets (pas de strFirstName)

  • Ne pas utiliser de mots-clés enregistrés pour les noms d'objets

  • Pas d'espaces ou de caractères spéciaux dans les noms d'objets (Alphanumber + Underscore sont les seules choses autorisées).

  • Nommer les objets de manière naturelle (FirstName au lieu de NameFirst)

  • Le nom de la table doit correspondre aux champs Nom et Description de la clé primaire (SalesType - SalesTypeId, SalesTypeDescription).

  • Ne pas préfixer avec tbl_ ou sp_.

  • Code de nom par nom d'objet (CustomerSearch, CustomerGetBalance)

  • Noms des objets de la base de données en CamelCase

  • Les noms de colonnes doivent être au singulier

  • Les noms des tables peuvent être au pluriel

  • Donner des noms commerciaux à toutes les contraintes (MustEnterFirstName)

Types de données

  • Utilisez le même type de variable dans toutes les tables (code postal - numérique dans une table et varchar dans une autre n'est pas une bonne idée).

  • Utilisez nNVarChar pour les informations relatives aux clients (nom, adresse(s)), etc. On ne sait jamais quand on peut devenir une multinationale.

En code

  • Les mots-clés sont toujours en MAJUSCULES

  • N'utilisez jamais de jointures implicites (syntaxe de la virgule) - utilisez toujours des INNER JOIN / OUTER JOIN explicites.

  • Un JOIN par ligne

  • Une clause WHERE par ligne

  • Pas de boucles - remplacer par une logique basée sur des ensembles

  • Utilisez les formes courtes des noms de table pour les alias plutôt que A, B, C

  • Évitez les déclencheurs, sauf s'il n'y a aucun recours

  • Évitez les curseurs comme la peste (lire http://www.sqlservercentral.com/articles/T-SQL/66097/ )

Documentation

  • Créer des diagrammes de base de données

  • Créer un dictionnaire de données

Normalisation et intégrité référentielle

  • Utilisez autant que possible des clés primaires à une seule colonne. Utilisez des contraintes uniques lorsque cela est nécessaire.

  • L'intégrité référentielle sera toujours respectée

  • Éviter ON DELETE CASCADE

  • OLTP doit être au moins 4NF

  • Évaluer chaque relation un-à-plusieurs comme une relation potentielle plusieurs-à-plusieurs.

  • Clés primaires non générées par l'utilisateur

  • Construire des modèles basés sur les insertions plutôt que sur les mises à jour

  • PK à FK doivent avoir le même nom (Employee.EmployeeId est le même champ que EmployeeSalary.EmployeeId)

  • Sauf en cas de double jointure (Person.PersonId joint PersonRelation.PersonId_Parent et PersonRelation.PersonId_Child).

Maintenance : exécuter des scripts périodiques pour trouver

  • Schéma sans table

  • Enregistrements orphelins

  • Tables sans clés primaires

  • Tables sans index

  • UDF non déterministe

  • Sauvegarde, Sauvegarde, Sauvegarde

Soyez bon

  • Soyez cohérent

  • Correction des erreurs maintenant

  • Lire le style de programmation SQL de Joe Celko (ISBN 978-0120887972)

10voto

cletus Points 276888

Mes critères pour Oracle sont :

  • Les mots clés sont toujours en MAJUSCULES ;
  • Les noms des objets de la base de données sont toujours en minuscules ;
  • Les underscores remplaceront les espaces (c'est-à-dire qu'il n'y aura pas de conventions de casse de type "camel" qui sont courantes sur, par exemple, SQL Server) ;
  • Les clés primaires seront presque toujours nommées "id" ;
  • L'intégrité référentielle sera respectée ;
  • Les valeurs entières (y compris les identifiants de table) seront généralement toujours NUMBER(19,0). La raison en est que cela correspond à un nombre entier signé de 64 bits, ce qui permet d'utiliser le type Java long au lieu du BigInteger, plus gênant ;
  • Malgré l'erreur d'appellation consistant à ajouter "_number" à certains noms de colonnes, le type de ces colonnes sera VARCHAR2 et non un type numérique. Les types de nombres sont réservés aux clés primaires et aux colonnes sur lesquelles vous effectuez des opérations arithmétiques ;
  • J'utilise toujours une clé primaire technique
  • Chaque table aura sa propre séquence pour la génération des clés. Le nom de cette séquence sera _seq.

Avec SQL Server, la seule modification consiste à utiliser la casse pour les noms d'objets de la base de données (c'est-à-dire PartyName au lieu de party_name).

Les requêtes ont tendance à être écrites sur plusieurs lignes, avec une clause ou une condition par ligne :

SELECT field1, field2, field2
FROM tablename t1
JOIN tablename2 t2 ON t1.id = t2.tablename_id
WHERE t1.field1 = 'blah'
AND t2.field2 = 'foo'

Si la clause SELECT est suffisamment longue, je la diviserai en un champ par ligne.

9voto

Edward Shtern Points 612
  • Nommez toutes les contraintes

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X