Est-il une convention de nommage pour MySQL?

Voici comment je le fais:

  1. Les noms de tables sont minuscules, utilise des traits de soulignement pour séparer les mots, et sont au singulier (par exemple foo, foo_bar, etc.
  2. J'en général (pas toujours) avoir un incrément automatique PK. J'utilise la convention suivante: tablename_id (par exemple foo_id, foo_bar_id, etc.).
  3. Lorsqu'une table contient une colonne est une clé étrangère, j'ai juste copier le nom de la colonne de la clé de tout ce tableau, il est venu. Par exemple, dire que le tableau foo_bar a la FK foo_id (où foo_id est le PK de foo).
  4. Lors de la définition des FKs pour appliquer l'intégrité référentielle, j'utilise la suite: tablename_fk_columnname (par exemple, poursuite de l'exemple 3, il serait foo_bar_foo_id). Puisque c'est un nom de table/colonne nom de l'association, il est garanti d'être unique dans la base de données.
  5. Je commande les colonnes comme ceci: PKs, FKs, puis le reste de colonnes par ordre alphabétique

Est-il un meilleur, plus standard façon de le faire?

  • Est-il de mal à utiliser pour l'auto incrément PK juste "id"? Pourquoi? Le nom de la colonne n'ont de sens que dans le contexte de la table. J'ai donc un "id" dans chaque tableau, et peut avoir de nombreuses id_<table_name> pour FK.
  • Je pense que la raison la plus simple contre c'est simplement pour des raisons de cohérence/simplicité. Plutôt que d'avoir id_tableB => oh non différentes-colonne nommée id, la cohérence de id_tableB => id_tableB a juste l'air plus propre... ou que l'OP t-il: foo_id => foo_id plutôt que foo_id => id
InformationsquelleAutor StackOverflowNewbie | 2011-10-26
  1. 98

    Je dirais que d'abord et avant tout: être cohérent.

    Je pense que vous y êtes presque avec les conventions que vous avez décrit dans votre question. Un couple de commentaires si:

    Points 1 et 2 sont bon je pense.

    Point 3 - malheureusement, ce n'est pas toujours possible. Pensez à comment vous débrouiller avec une seule table foo_bar qui a des colonnes foo_id et another_foo_id tous deux référence à la foo table foo_id colonne. Vous pourriez envisager de la façon de traiter avec cela. C'est un peu un cas de coin si!

    Point 4 - Semblable au Point 3. Vous pouvez introduire un numéro à la fin du nom de clé étrangère pour satisfaire plus d'un que le référencement colonne.

    Point 5 - je voudrais éviter cela. Il vous offre un peu et va devenir un casse-tête lorsque vous souhaitez ajouter ou supprimer des colonnes dans un tableau à une date ultérieure.

    Quelques autres points sont:

    Indice Des Conventions De Nommage

    Vous pouvez introduire une convention de nommage pour les index, ce sera d'une grande aide pour toutes les métadonnées de la base de travail que vous souhaitez effectuer. Par exemple, vous pourriez juste voulez l'appeler un index foo_bar_idx1 ou foo_idx1 - totalement à vous, mais à considérer.

    Singulier vs Pluriel des Noms de Colonne

    Il pourrait être une bonne idée d'aborder le problème épineux du pluriel vs seul dans vos noms de colonne ainsi que le nom de votre table(s). Ce sujet provoque souvent des de grands débats dans la base de données de la communauté. Je m'en tiendrais singulière, les formulaires pour les noms de tables et de colonnes. Il n'. Je l'ai déjà dit.

    La chose principale ici est bien sûr de cohérence!

    • Quoi de mieux que de le point 5? Pourquoi il pourrait devenir un casse-tête?
    • Pour suivre, j'ai trouvé cela très utile pour ceux qui viendront plus tard: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/...
    • Je vais avoir du mal à trouver un bon "régime" pour nommer mes tables qui détiennent des objets de modèles composés de deux noms (DocumentChapter, DocumentVersion, DocumentType etc.). Par exemple pour DocumentType je pouvais lui donner un nom documenttype ou document_type. Je préfère la dernière, mais la plupart du temps j'ai une relation plusieurs-à-plusieurs et j'ai besoin d'un tableau ressemblant à document_document_type. Toutes les suggestions comment gérer cela?
    • Re: le point 5 - Après l'ajout d'une colonne (à la fin), l'ordre pourrait devenir invalide. Vous ne devez pas ajouter une contrainte qui nécessite de réorganiser les colonnes que c'est une surcharge inutile.
    InformationsquelleAutor Tom Mac
  2. 20

    La cohérence est la clé de tout standard de nommage. Tant que c'est logique et cohérent, vous êtes à 99%.

    La norme elle-même est beaucoup question de préférence personnelle - donc si vous aimez votre standard, puis courir avec lui.

    Pour répondre à votre question carrément - non, MySQL n'a pas de préférence pour un convention de nommage/standard, le déploiement de votre propre est très bien (et le vôtre me semble logique).

    InformationsquelleAutor mal-wan
  3. 7

    MySQL a une courte description de leur plus ou moins à des règles strictes:

    https://dev.mysql.com/doc/internals/en/coding-style.html

    Plus courantes codingstyle pour MySQL par Simon Holywell:

    http://www.sqlstyle.guide/

    Voir aussi cette question:
    Y sont publiés style de codage des lignes directrices pour SQL?

    InformationsquelleAutor Daniel W.
  4. 4

    Heureusement, les développeurs PHP ne sont pas "Chameau cas bigots" comme certains le développement des communautés que je connais.

    Vos conventions de son amende.

    Tant qu'ils sont une) simple, et b) constant, je ne vois pas de problèmes 🙂

    PS:
    Personnellement, je pense que 5), c'est du matraquage...

    • Loin d'être des fanatiques, à dos de chameau cas est mal vu par beaucoup de la DB de la communauté parce que certains SGBDR' sont insensibles à la casse, au point où ils auront la bande de cas (ou de modifier tout en majuscules), alors les choses deviennent vraiment laid vraiment rapidement.
    • pouvez-vous préciser ce qui SGBDR'? Et je suis un chameau cas le jockey moi-même. Bouchons servent un seul but dans mon schéma, pour indiquer les tables de jointure et (dans le cas de champs) pour indiquer les limites de mot, de sorte que l' _ peut être exclusivement pour indiquer un othertable_id (c'est à dire nom de la table = othertable et le champ dans la table = id). En outre, si les autres SGBDR est insensible à la casse, qu'est-il vraiment de l'importance? Je ne vais jamais à avoir une majuscules et minuscules version de la même table! Oh, et je préférerais pas un casse SGBDR - je serais plutôt de l'écrire cohérente code
    • J'aime l'ironie de l'utilisateur MySQL n'aime pas CamelCase et le nom du produit que nous utilisons: MySQL, écrit en CamelCase
    • Pour être pédant, c'est PascalCase, pas camelCase, mais votre point de vue, est encore debout.
    • Jamais pensé à ça, mais vous avez raison. camelCase devriez pas avoir de bosse au début.
    InformationsquelleAutor paulsm4