par
sadeq » 23 juin 2008, 14:49
Selon toute logique on doit prendre en compte à la fois l'ergonomie du codage SQL et la charge réseau.
En effet les noms longs alourdissent les formules de codage des requêtes même s'ils augmentent la lisibilité. Et augmentent la taille des requêtes transmises au serveur ce qui surcharge le trafic réseau. Mais on peut réconcilier entre l'avantage et l'inconvénient en utilisant un codage de nom raisonnablement court sans perdre la lisibilité des noms (rapport nom/rôle de l'objet nommé) dans la limite d'une huitaine de caractères. Par exemple : nommer un champ "id_cli" au lieu de "identifiant_client" et "adr_frss" au lieu de "adresse_fournisseur" etc...
Selon toute logique on doit prendre en compte à la fois l'ergonomie du codage SQL et la charge réseau.
En effet les noms longs alourdissent les formules de codage des requêtes même s'ils augmentent la lisibilité. Et augmentent la taille des requêtes transmises au serveur ce qui surcharge le trafic réseau. Mais on peut réconcilier entre l'avantage et l'inconvénient en utilisant un codage de nom raisonnablement court sans perdre la lisibilité des noms (rapport nom/rôle de l'objet nommé) dans la limite d'une huitaine de caractères. Par exemple : nommer un champ "id_cli" au lieu de "identifiant_client" et "adr_frss" au lieu de "adresse_fournisseur" etc...
