MarcWiki

Le wiki de Marc Meurrens
connexion :
Help > Home > Tech > MySql >
Resp. Mise à jour 31 Décembre 2009 à 15h30 par
Mes conventions de nommage en MySql
en construction !

mes conventions de nommage des tables et des champs(fields) en mySql

Pourquoi?

Ces conventions ne sont ni meilleures ni pires que d'autres.
Elles sont certainement meilleures que pas de convention du tout.

Elles me permettent et permettent à mes collaborateurs de comprendre très rapidement le travail de chacun. Et de détecter, le plus rapidement possible dans le processus de développement, d'éventuelles incohérences.

Elles nous permettent certains traitements automatiques.
Exemple :
Si la table tools_people contient les champs:
  • url_site
  • sz_url_site
la convention de nommage permet, par exemple, de générer automatiquement, pour un objet, lu depuis la DB, qui contiendrait $people->url_site et $people->sz_url_site un troisième attribut $people->html_link_site dont le contenu serait quelque chose comme '<a href= . quote($people->url_site) . '>' . htmlEntities($people->sz_url_site) . '</a>'

∴

Domaines

Une même DB peut contenir des tables relatives à différentes applications ou sous-applications, par exemple:
  • tools (tables du framework), exemple :
    • tools_country_iso_pk : une table des pays (inutile de mettre country au pluriel: il y a bien sûr plusieurs entrées), appartenant au framework, dans la clef primaire n'est pas le traditionnel pid mais bien a2_iso.
    • diverses tables utilisées par la plupart des applications
  • mason : exemple :
    • mason_obed
  • agenda : exemple :
    • agenda_auditable_meeting : une table des réunions, appartenant à l'application agenda et qui contient un pointeur vers la table tools_audit
∴

Tables

Le nom d'une table commence toujours par le domaine.
Ceci est en outre utile pour ne pas se mélanger les pinceaux en cas d'hébergement prévoyant un nombre limité de DB, et où divers logiciels installeront, chacun, leurs tables respectives avec un préfixe différent.
∴

Tables particulières

Menu

Une table contenant des choix, par exemple pour un menu déroulant.
Exemple :
  • agenda_menu_fr_type_activite : une liste de types d'activités pour laquelle le texte descriptif est en UTF8, écrit en français et traduisible dans d'autres langues. Typiquement, une telle table comprendrait les champs[1] suivants :
    • us_value_pk : une valeur entière(us_value_pk) positive ou nulle (us_value_pk) petite (us[2]_value_pk) qui constitue la clef primaire pour cette table (us_value_pk)
    • szm_legend : le texte correspondant, UTF8 (szm_legend), en français (agenda_menu_fr_type_activite), traduisible, correspondant à la version middle(szm_legend) dans la table tools_babel.
  • sz_comment[3] : un commentaire à usage interne [4], un texte non traduisible en UTF8 (sz_comment).
∴

Doc

Exemple :
  • agenda_doc_diffusion : une table à usage interne assez semblable à une table menu sauf qu'elle ne contient pas un champ du genre szm_legend.
∴

Auditable

Une table dont les données sont sensibles et qui contient un pointeur vers la table tools_audit.
Exemple :
  • agenda_auditable_meeting : une table des réunions, appartenant à l'application agenda et qui contient un pointeur vers la table tools_audit
∴

N x N

Exemple :
  • agenda_assoc_2_reunion
∴

Pour les tables particulières, le nom de la table est construit par le nom du domaine, suivi de :
  • _menu_ lui même suivi du code ISO 3166 (non qualifié) de la langue en 2 ou 3[5] lettres. Exemple :
    • _menu_fr_
  • _doc_
  • _auditable_
  • le noms (ou évocations) des tables liées séparés par _2_ [6]
∴

Champs (fields)

Préfixe et suffixe

Tous les champs sont nommés à l'aide d'un préfixe[7], parfois suivi d'un deuxième préfixe (e.g. default, url...).
Lorsqu'un champ constitue la clef primaire((primary key):
  • soit, dans la plupart des cas, il s'agit d'une clef entière, un entier positif non nul, sur 11 caractères, toujours appellé pid
  • soit c'est un autre champ et dans ce cas on mentionne le suffixe _pk (comme primary key)
∴

Premier Préfixes

Le premier préfixe indique le type du contenu.

Ce n'est pas nécessairement une indication suffisante du type défini en mySql. Exemple: html_signature peut être un VARCHAR(256) ou un TEXT.
Clefs et pointeurs
  • pid
  • pointeur avec valeur 0 admise :
    • id_domaine_tabledunautredomaine
      • id_tools_people
    • id_tabledumemedomaine
      • id_reunion
  • pointeur vers un record qui DOIT exister :
    • id_mandatory_xxx
∴

Numériques
  • i_ : integer
  • u_ : unsigned integer
  • ul_ : unsigned long integer
  • us_ : unsigned short integer
  • o_ : offset (auusi l'initiale de order)
  • time_ : unix time (nr of seconds since Unix epoch = 1/1/1970)
  • latitude_ (double)
  • longitude_ (double)
  • f_ : float
  • d_ : double
∴

Logiques
  • z_ : 0 ou 1
  • yn_ : 'Y' ou 'N'
  • ynq_ : enum('Y','N','Q') yes, no, '?'
  • ynx_ : enum('Y','N','X') yes, no, N/A (not applicable)
  • ynqx_ : enum('Y','N','Q', 'X') yes, no, '?' , N/A
  • fz_ : fuzzy, 0 ≤ float ≤ 1
  • e7_ : enum avec 7 valeurs possibles (exemple !)
  • e_amde_ : enum('A','M','D','E') (exemple!)
∴

Caractères
  • ch_ : un caractère UTF8
  • a2_ : code en 2 lettres (ex. country ISO 639 : it, be)
    • a2_639_
    • regex : /^[a-z]{2,2}$/
  • a3_ : code en 2 ou 3 lettres (ex. language ISO 3166 : es, ast)
    • a3_3166_destination_country
      • regex : /^[a-z]{2,3}$/
    • a3_country_or_region
      • 'fr', 'cu', 'lat' , 'eur' , 'bxl'...
  • a6_ : code jusqu'à 6 lettres ou chiffres : es-CU, fr, ...
    • a6_3166_
      • regex : /^[a-z]{2,3}(\-[A-Z]{2,2})?$/
    • a16_3166_ ( zh-Hans )
      • regex : /^[a-z]{2,3}(\-[A-Z][a-zA-Z]{1,11})?$/
∴

Textes Ascii
  • asc_16_
  • asc_32_
  • asc_64_
  • asc_128_
  • asc_256_
∴

Texte UTF8
  • sz_ : non traduisible
  • szs_ : traduisible, correspond à un champ 'short' dans la table tools_babel
  • szm_ : middle
  • szl_ : long
  • txt_ : non traduisible
∴

Textes particuliers
  • date_ (exemple : 1789-07-14 ) correspond à DATE en mySql
  • datehour_ (exemple : 1789-07-14 15:59:30) (à vérifier !!!!)
  • dater_ (RFC ? ) utiliser plutôt time_ !
  • datec_ (RFC ? ) utiliser plutôt time_ !
  • url_ : y compris le protocole
  • http_ : le protocole sera ajouté ( les 7 caractères : http:// )
  • email_ (à préférer àurl_email_truc qui contiendrait mailto:truc@machin.org)
  • html_ :
  • isbn_ :
  • sis_ :
  • sql_ : query
  • regex_ :
  • shell_ :
  • php_ :
  • ip4_ : exemple : 164.15.233.25 : 3 points + 4x3 ⇒ {7,15}
  • ip6_ :
  • zip_ : (pays{1,3} + '-')? + 4 (be,ch), 5 (fr) or up to 7 chars (ca, uk : 3,space,3) {4,7} ⇒ pour être sûr {4,16}
∴

Valeurs multiples
  • csv_ :
    • csv_a3_3166_langues_interface (exemple : ,'it','es','fr', )
      • first/last commas added to facilitate mySql LIKE's
      • génération automatique de :
        • $obj->o_2_a3_3166_langues_interface = array('it','es','fr') ;
        • $obj->a3_3166_langues_interface_2_o = array('it'=>0,'es'=>1,'fr'=>2) ;
∴

Second Préfixes

Le second préfixe indique l'usage du contenu
ou la norme respectée.
mandatory
optional
  • id_mandatory_audit : le pointeur doit pointer vers une valeur existante du pid dans la table tools_audit
par opposition à :
  • id_lieu_villegiature : pointeur optionnel vers la table lieu. Une alertnative explicite (mais optional est compris par défaut):
  • id_optional_lieu_villegiature
∴

default
  • _default_
La valeur n'est pas véritablement liée à l'objet décrit mais constitue la valeur par défaut qui sera utilisée dans une autre table.
Exemple :
  • la table monapplic_type_reponse contient les champs :
    • pid
    • ynq_default_satisfait
  • la table monapplic_reponse contient les champs :
    • id_type_reponse
    • ynq_satisfait
∴

url, email, http
  • _http_
  • _email_
  • _url_
Exemples :
  • la table tools_people contient les champs:
    • url_image
    • sz_url_image
    • url_site
    • sz_url_site
∴

Pourquoi?
La convention de nommage permet par exemple de générer automatiquement, pour un objet, lu depuis la DB, qui contiendrait $people->url_site et $people->sz_url_site un troisième attribut $people->html_link_site dont le contenu serait quelque chose comme '<a href= . quote($people->url_site) . '>' . htmlEntities($people->sz_url_site) . '</a>'
∴

normes, etc
  • a2_639_
  • a3_3166_
  • a6_3166_
  • a16_3166_
pour un standard ISO

idem pour RFC (voir datec , dater !!!)
  • date_???_ selon RFC ??? en PHP date($t,'r')
  • date_r_ selon RFC ??? en PHP date($t,'r')
  • date_???_ selon RFC ??? en PHP date($t,'c')
  • date_c_ selon RFC ??? en PHP date($t,'c')

ou pour d'autres standards...
  • ip4_ : on ne précise pas IANA, le 4 de ip4 est suffisant!
∴

Suffixe

  • _pk
Lorsqu'un champ constitue la clef primaire :
  • soit, dans la plupart des cas, il s'agit d'une clef entière, un entier positif non nul, sur 11 caractères, toujours appellé pid
  • soit c'est un autre champ et dans ce cas on mentionne le suffixe _pk (comme primary key)
∴
[1] fields
[2] short
[3] éventuellement
[4] documentation pour les développeurs
[5] rare, exemple ast = asturien (babel)
[6] prononcer to, bien que 2 serait two..., les informaticiens étant de gentils farceurs plus sensibles à la phonétique qu'à l'orthographe, ainsi le symbole mathématique ∴ (therefor) est allègrement nommé there4...
[7] cfr. hungarian prefix
 Ajouter un commentaire