Discussion :

[SQL_EVAN]

En lisant des bouquins et des informations sur des sites reconnus je vois souvent des différences sur la casse. Des fois c'est en camelCase (TableFactures) et très souvent c'est en majuscule (TABLE_FACTURES) Ce qui est notamment le cas dans SQL par F Brouard, R Bruchez et C Soutou.

Moi, j'ai toujours envie de conceptualiser mes bases en majuscules mais souvent cela ne colle pas avec les dev.

Un exemple récent. On dev sur azure en C# et le dev lead a souhaité utiliser un design pattern MVC. Donc le problème c'est que son outil lui génère ses objets à partir des entités en base et donc cela lui fait un framework qui ne colle pas avec les normes C# (camelCase).

J'ai été donc obligé de recréer le schéma avec la nomenclature camelCase.

Y a t-il pas une solution pour cela sauf de créer des vues à droite et à gauche qui créent une usine à gaz?

Est-ce pas plus logique de travailler toujours en camelCase? Si cela est le cas pourquoi écrire des livres avec des modèles nommés en majuscule?

[aieeeuuuuu]

Bonjour,

Bien souvent, tout ce qui est de près ou de loin du SQL s'écrit en majuscule. Historiquement, à l'époque ou l'on écrivait le code SQL dans les programmes, cela permettait de différencier facilement le code applicatif du code SQL.

Les méthodes ont changé, mais les habitude sont restées. Cependant, ce n'est nullement une obligation. Chacun reste libre de définir ses propres règles de nommage...

Y a t-il pas une solution pour cela sauf de créer des vues à droite et à gauche qui créent une usine à gaz?

Cela ne crée pas une usine à gaz, mais ce qu'on appelle un modèle externe de données. Bien que peu répandu, cela reste pourtant une bonne pratique.
Rien ne vous empêche de créer un schéma pour contenir ces vues, ceci réduira votre impression d'usine a gaz : vous avez vos tables d'un coté, normalisées, avec la convention de nommage qui vous semble la plus adaptée, et vos vues de l'autre. Votre application n'accède jamais directement à vos tables, mais passe par vos vues. La encore, chacun est libre de choisir, mais le nommage de vos vues peut s'adapter aux conventions que vous utilisez dans votre code applicatif.
Même si cette solution semble plus lourde à mettre en place, elle présente à long terme de nombreux avantages, notamment de pouvoir modifier votre modèle de données sans modifier votre code applicatif...

Enfin, il me semble que la plupart des ORM permettent de renommer les objets qu'ils mappent, ça reste une alternative.

[SQL_EVAN]

Super réponse et ça correspond bien avec mes avis. Je vais peut-être utiliser des vues dès le début alors avec le système de schémas.

Je n'avais jamais pensé au fait que les majuscules permettaient de voir les différences dans les anciennes pages de code. Bien à savoir ça.

Merci.

[iberserk]

attention, en créant des vues votre "dev lead" (ils en invente tous les jours!) va encore venir pleurnicher car sauf erreur de ma part, LUNQ TO ENTITIES (car il s'agit assurément de lui!) sera incapable de créer lui même les liaisons entre les entités ARGGHHH

Mais s'il est en V4 il doit se baser sur le POCO et s'il est malin il peut passer par des outils capable de générer eux même les noms d'entité en fonction de pattern paramétrable...

[SQL_EVAN]

C'est vrai, ça crée pas mal de travail pour rien au final. Je vais laisser les tables en camelCase je pense et arrêter de me plaindre haha

[SQLpro]

Rien ne vous empêche de créer des trigger DDL détectant les CREATE et ALTER TABLE, faire un ROLLBACK,t aller majusculiser la commande SQL et la relancer !

A +