dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] BDD - cles primaires


From: Gael Canal
Subject: Re: [Dolibarr-dev] BDD - cles primaires
Date: Mon, 05 Dec 2005 14:30:23 +0100

Le lundi 05 décembre 2005 à 09:59 +0100, Rodolphe Quiedeville a écrit :
> Gael Canal wrote:

> ok pour une charte de nommage mais personnellement je trouve que
> beaucoup de charte de nommage sont un vrai cauchemar pour les codeurs,
> il faut bien voir que nous avons sous les yeux à longueur de journées
> des noms de champs et de tables alors pitié pas de charte inesthétique ;-)

J'en conviens volontiers, et je reconnais qu'il est pénible de se plier
à des contraintes lorsque l'on code.

> > suffixer le nom de la table de _id (pour la clé primaire),
> 
> Typiquement je ne suis pas pour, rowid me parait très bien comme clé
> primaire parce que je me vois mal taper tous les le jour le nom de la
> clé primaire de la table llx_telephonie_distributeur_commerciaux

Juste histoire de donner une seconde chance à ma proposition, je propose
quelques contre arguments :

1. il y a toujours le copier-coller

2. il y a toujours la possibilité (et c'est même une bonne idée) de
réutiliser le code

3. pour les cas extrême, dans le dispositif que je propose, on peut
toujours faire :
$table="telephonie_distributeur_commerciaux";
$sql="select cod_$table, lib_$table from $table where id_$table=12";
etc...

4. l'utilisation systématique de rowid est-elle plus une aide pour les
développeurs qu'une clé primaire aisément identifiable et ratachée à une
table ?
Est-ce que le code n'est pas plus lisible dans le cas xxx_id ?
Dans le cas de requetes complexes incluant plusieurs tables, est-ce que
plusieurs rowid n'est pas susceptible de générer des bugs / confusions
etc..

Je comprend que cette proposition soit lourde de conséquences, non pas
pour une question d'habitude de codeurs qui en ont vu d'autres, ni pour
la longueur des noms de champs, après tout, mysql_real_escape_string est
assez long a taper aussi, mais surtout pour ce qu'elle impliquerait en
adaptation du code existant; je n'espère donc pas qu'elles soit adoptée
sous les vivas :-)

Les problèmes de réalisation du MPD ne sont pas vraiment le problème,
mais, je souhaitais attirer votre attention sur cette question, car
dolibarr atteint une masse critique de plus d'une centaine de tables, et
que la maintenabilité du code au dela d'un certain point risque d'être
compromise faute de standards de codage.

Un MPD peut aider à cela; un code bien documenté aussi; des règles de
codage aussi etc... c'est juste un tout.

...au moins j'aurais essayé :-)
++
Gael





reply via email to

[Prev in Thread] Current Thread [Next in Thread]