Discussion :

[kedare]

Ca me parait pourtant évident d'utiliser l'anglais partout, de toute façon l'anglais est déjà partout, 90% de la documentation est en anglais, 90% du support et de l'assistance est en anglais.
De toute façon, tout les (bon) professionnels de l'informatique doivent avoir une parfaite maîtrise de l'anglais.

[Kwadz]

Au sujet des majuscules/minuscules :
Tous les EDI gérant la coloration syntaxique, le code SQL entre guillemets se retrouve coloré et donc déjà différencié du reste du code (Java, PHP, C++, etc.). Ceci étant, il parait plus facile d’utiliser des majuscules et minuscules dans le code SQL pour distinguer les instructions des noms de table et colonne.

Une question concernant le préfixage :
Lors d’une génération automatique des entités ORM à partir d’une base de données, le préfixage se retrouve dans les noms d’entité et de leurs attributs. Conseilleriez-vous de garder ces préfixes dans les entités ou de réaliser tout un travail de conversion à la main ?

[CinePhil]

Lors d’une génération automatique des entités ORM à partir d’une base de données, le préfixage se retrouve dans les noms d’entité et de leurs attributs. Conseilleriez-vous de garder ces préfixes dans les entités ou de réaliser tout un travail de conversion à la main ?

Mieux : Ne pas utiliser d'Objet Réellement Merdique !

[Kwadz]

Certes j'ai aussi été un peu déboussolé au départ avec les ORM, pourtant à l'utilisation j'ai constaté qu'ils pouvaient s'avérer vraiment très pratiques. Rien n'oblige à les utiliser tout le temps au lieu d'utiliser directement une requête SQL quand cela est plus judicieux (ou obligatoire).

Quant à ma question je pense que les conventions de nommage du monde relationnel deviennent caduques au sein d'entités ORM. J'aurais toutefois souhaité avoir des avis pertinent sur le sujet.

[Mathiewe]

Bonjour,

Je serais intéressé moi aussi pour connaître les bonnes pratiques des conventions de nommage pour les entités lors de leur génération à partir d'une base de données. Est-ce qu'il existe des outils qui font le sale boulot (suppression des préfixes, etc.) ?

Merci

[vince-nantes]

Bonjour,

J'aimerais avoir des avis sur des questions que je me pose, notamment ceux de SQLpro et CinePhil qui me semblent experts en la matière. Je suis chargé, avec mes collègues de travail, de remodéliser un système d'information avec plus de 100 tables donc nous souhaitons le faire correctement.

J'ai appris Merise en BTS Informatique de Gestion et on m'a enseigné de modéliser comme ça : "bdd1.gif" (ci-dessous).

J'ai volontairement pris un exemple simple, modélisé avec SQLYog.
J'utilise donc un suffixe (ex:_client) sur les champs, reprenant le nom de la table, ce qui m'assure de ne pas avoir de doublon. Pour moi, ça me semble revenir au même que la méthode de SQLpro avec des préfixes.
Je trouve ça pratique également car je trouve que ça décrit bien l'information (ex:nom_client) et je me sers toujours de ce même nom, que ce soit dans ma BDD ou dans mes variables PHP. C'est ainsi facile à retenir et à relire par d'autres développeurs.

Mes collègues de travail, qui n'ont pas étudié Merise, utilisent une modélisation différente : "bdd2.gif" (ci-dessous).

Pour simplifier les champs de la BDD, ils utilisent donc parfois des doublons (ex:nom).

Ma question est de savoir si leur solution peut poser problème et surtout d'avoir des exemples concrets de problème.

Personnellement, je trouve également que les champs de table sont plus faciles à lire (car plus simples), mais ça me dérange car on m'a appris à ne jamais avoir de doublon et ça alourdit également les requètes SQL :

Avec ma façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT
  C.nom_client,
  C.prenom_client,
  V.nom_ville
FROM client C
NATURAL JOIN ville V

Avec leur façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT
  C.nom AS nom_client,
  C.prenom,
  V.nom AS nom_ville
FROM client C
NATURAL JOIN ville V

Ils sont donc contraints de mettre des alias sur les champs portant le même nom, ce qui pourrait provoquer des risques d'erreur si on oublie que plusieurs champs portent le même nom. Dans une grosse BDD, le risque me semble élevé.
Ou alors il faudrait mettre des alias de champs partout, ce qui alourdit l'écriture et la lisibilité de la requète.

Je crois me souvenir que le dictionnaire de données servait justement à détecter qu'il n'y avait pas de doublon dans la BDD, donc leur modélisation poserait problème, mais je ne l'ai jamais vu ou utilisé en entreprise. Est-il souvent utilisé ? par qui et dans quel but ?

Est-ce que leur méthode peut poser problème également au niveau de la rétro ingénierie au niveau MCD, comme l'évoquait SQLpro ? Si oui, est-ce souvent utilisé en entreprise et quels sont les outils ?

Merci d'avance pour vos réponses.

[CinePhil]

1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

2) Vos schémas ne sont pas tout à fait des schémas merisiens.
Cela ressemble plus au "schéma des relations" d'Access ou, à la rigueur, à un "entity/relationship diagram" à la mode MySQL Workbench.

D'ailleurs, ton message n'a pas grand chose à voir avec Merise qui est une méthode de conception et développement de systèmes d'informations.

3) Les logiciels de modélisation ont certains automatismes pour dériver un MCD en MLD ou en diagramme entité/association ou pour directement proposer un nom pour les nouvelles propriétés dans les entités types...

Analyse SI interdisait deux propriétés de même nom. Je ne sais pas si c'est toujours le cas. C'est peut-être paramétrable dans d'autres modeleurs.

4) Évite le NATURAL JOIN.
Si un nom de colonne impliqué dans une jointure change, la jointure naturelle ne fonctionnera plus. Il vaut bien mieux écrire les conditions de jointure en clair afin de lever toute ambiguïté.

Comme je l'ai déjà dit ici ou ailleurs, j'ai adapté le standard de nommage de SQLPro et je m'en porte très bien. Voir mon message du 20/10/2010 15h27 dans cette discussion pour le détail de mes adaptations.


Puisque ton boulot semble être de reconcevoir la BDD, déduis le MLD de la structure actuelle implémentée puis essaie de retrouver le MCD correspondant, corrige-le, améliore-le pour faire le nouveau MCD (ou s'il est vraiment pourri, repars de zéro ! ) puis dérive en MLD afin de générer ensuite les nouvelles tables.

Et adopte un standard de nommage.

[vince-nantes]

Tout d'abord merci pour ta réponse
Malgré tout je n'ai pas la réponse à ma question : est-ce que leur modélisation peut poser des problèmes concrets ?

1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

Coupable

2) Vos schémas ne sont pas tout à fait des schémas merisiens.

Pas tout à fait coupable, ma modélisation découle directement de Merise (CLIENT 1,1 --- CIF --- 1,n VILLE), c'est juste un exemple simple pour que tout le monde comprenne, même s'il est contestable au niveau des cardinalités, mais là n'est pas le propos.

3) Les logiciels de modélisation ont certains automatismes pour dériver un MCD en MLD ou en diagramme entité/association ou pour directement proposer un nom pour les nouvelles propriétés dans les entités types....

Merci mais ils sont souvent utilisé en entreprise ?

4) Évite le NATURAL JOIN

En fait, j'évite aussi de l'utiliser mais je l'ai écris ici car j'ai vu que plusieurs personnes sur ce sujet l'utilisent, je préfère utiliser USING ou écrire les critères de jointure comme tu le fais.

ou s'il est vraiment pourri, repars de zéro !

Il est hyper pourri malheureusement, ce n'était pas un vrai informaticien qui l'a créé, mieux vaut repartir de zéro.

[CinePhil]

est-ce que leur modélisation peut poser des problèmes concrets ?

Tu avais donné toi même une source de problèmes :

Ils sont donc contraints de mettre des alias sur les champs portant le même nom, ce qui pourrait provoquer des risques d'erreur si on oublie que plusieurs champs portent le même nom. Dans une grosse BDD, le risque me semble élevé.

Il m'est arrivé plusieurs fois dans les forums ici même de me demander de quelle table provient telle colonne et de recommander dans ma réponse que l'auteur de la discussion utilise au moins des alias et complète les blancs dans ma réécriture de sa requête.

Quitte à repartir de zéro, et pour faire les choses bien dès le départ, je répète : définis une norme de nommage qui tienne la route.

[vince-nantes]

Merci pour ta réponse.

Si quelqu'un a d'autres idées, je suis preneur.

[CinePhil]

Au fait, tu as le droit de demander de l'aide pour le nouveau MCD dans le forum Schéma.

Bon courage !

[SQLpro]

Joe Celko a écrit un ouvrage sur le sujet de nom "SQL Style", adoptant la notation américaine pointée...Je lui ais simplement fait remarquer que pour certaines recherches, notamment dans les vues cette méthode conduisait à des impasses que la notation trigramisée, lorsqu'elle est correctement appliquée, évite totalement. Voici ce que j'ai publié à ce sujet :
http://blog.developpez.com/sqlpro/p7...ention_help_to

A +

[CinePhil]

C'est quoi la "notation américaine pointée" ?

[SQLpro]

MonObjet.MonMachin.MonBidule.MonTruc.Monzigouigoui.MaChose...

A +

[CinePhil]

C'est sûr que si on utilise ça dans du SQL, ça risque d'être mal interprété !
SELECT MonObjet.MonMachin = Sélectionne la colonne MonMachin de la table MonObjet.
On ne peut pas nommer un objet de la sorte dans une BDD SQL !