Discussion :

[L. Sierra]

Salut à tous,

Je ne suis pas un expert en DB mais depuis quelque temps de travaille beaucoup avec (MySQL en l'occurrence).

Au début c'était simple, j'ai travaillé sur une DB contenant des données relatives à un seul projet. A présent la DB doit se décliner en plusieurs projet, chacun ayant plusieurs versions.

Deux solutions me viennent à l'esprit:
-> ajouter un champ Project_ID/version_ID à chaque table
-> avoir plusieurs DB dont les schémas seraient identiques et dont le nom contient le nom du projet et le numero de version

La seconde solution me paraît originale et je voulais savoir si elle est utilisée dans la pratique pour de grandes DB. Pensez vous que c'est une solution viable, en particulier s'il fallait utiliser des trigger pour effectuer des modifications qui impliquent des changements dans plusieurs DB ?

Merci d'avance pour vos avis

[chaplin]

Est ce que les données sont centralisées sur un serveur ?

[CinePhil]

Ta notion de 'projet' recouvre quoi ?
1) Une entreprise réalise des projets et gère des données relatives à ces projets. La base de données doit modéliser la gestion des données relatives aux projets.
Exemple : une entreprise de bâtiment qui réalise des projets de construction.

2) Ce sont des projets informatiques totalement indépendants les uns des autres qui ont chacun leurs données indépendantes à gérer par des bases de données indépendantes.
Exemple : un projet de gestion de location de véhicules et un projet de vente de vin par internet.

[L. Sierra]

Est ce que les données sont centralisées sur un serveur

Oui c'est un seul serveur qui contient toutles les données

Ta notion de 'projet' recouvre quoi ?
1) Une entreprise réalise des projets et gère des données relatives à ces projets. La base de données doit modéliser la gestion des données relatives aux projets.
Exemple : une entreprise de bâtiment qui réalise des projets de construction.

2) Ce sont des projets informatiques totalement indépendants les uns des autres qui ont chacun leurs données indépendantes à gérer par des bases de données indépendantes.
Exemple : un projet de gestion de location de véhicules et un projet de vente de vin par internet.

C'est le 1) donc plusieurs projets très similaires et parfois inter connectés, qui ont des influences les uns sur les autres.

[CinePhil]

Donc 1 seule base de données.

Tu prendras bien un peu de Merise ?

Règle de gestion :
"Un projet peut exister en plusieurs versions et une version n'appartient qu'à un seul projet"

MCD :
Projet -1,n----Exister----1,1- Version

Tables :
Projets(Pr_Id, ...)
VersionsProjets(VP_Id, VP_IdProjet, ...)

Après il faudrait nous en dire plus sur ton modèle pour t'aider à le modifier.
Tu peux déjà voir qu'il faut associer à la table Projets ce qui concerne les projets et à la table Versions ce qui dépend des versions de projets.

Par exemple...
Règle de gestion :
"Un projet est géré par un et une seule personne en tant que chef de projet et un chef de projet peut gérer plusieurs projets."

MCD :
Personne -0,n----Gérer----1,1- Projet

Tables :
Personnes(P_Id, ...)
Projets(Pr_Id, Pr_IdChefProjet, ...)


Etc...

[chaplin]

Donc j'opterais pour cette option:

-> ajouter un champ Project_ID/version_ID à chaque table

Peut être que des tuples de certaines entités seront communs aux projets, donc pour celles ci, il ne sera pas necessaire de le faire si j'ai bien compris le cheminement de pensée de CinéPhil .

[L. Sierra]

Peut être que certaines les tuples de certaines entités seront communs aux projets, donc pour celles ci, il ne sera pas necessaire de le faire si j'ai bien compris le cheminement de pensée de CinéPhil .

Moi aussi j'ai un peu de mal à comprendre CinéPhil, mais que veux tu, les voies des génies (photo d'Einstein) sont impénétrables

Je tombe le masque ! Contrairement à ce que j'ai dit plus haut, l'option du Project_ID me semble aussi la plus évidente... J'ai un collègue qui a déja de l'expérience en DB qui pense la même chose que moi. Si je posais cette question sur le forum, c'était juste pour vérifier un truc: mon chef de projet est bien le seul à choisir (m'imposer) l'option de plusieurs schémas similaires sur le serveur

Enfin, je ne désespère pas (encore) de trouver quelqu'un qui adopte la seconde option sans hésiter

[JPhi33]

Bonjour,

[...] plusieurs projets très similaires et parfois inter connectés, qui ont des influences les uns sur les autres.

A mon sens, cette phrase est très importante et influence la décision en faveur d'une base de données unique.

En effet, si on choisit l'option 1 bdd par projet, immédiatement viennent des questions du genre :

• Comment garantir la cohérence des données entre les différentes bdd ?
• Puisque les projets sont influencés les uns par les autres, y a-t-il des données communes ? Si oui, où les stocker ? Dans chaque bdd (--> redondance) ? Dans une autre bdd à part ?
• Quelles conséquences peuvent avoir la gestion de plusieurs bdd sur les performances de l'application si les données sont fortement interconnectées (problème de va-et-vient entre les bdd) ?
• La création d'un nouveau projet implique donc la création d'une nouvelle bdd. Est-ce bien raisonnable ?
• etc.

Je te suggères de poser ces questions à ton CP, tu verras bien ce qu'il répond.


JPhi33

[L. Sierra]

Je te suggères de poser ces questions à ton CP, tu verras bien ce qu'il répond.

CP = chef programmeur ?

J'ai évidemment soulevé le problème des inter-connexions, car certains éléments devront être communs à plusieurs BDD. Sa réponse a été très simple: il y a encore des points à analyser mais nous commençons ainsi et nous verrons plus tard pour le reste. Un de mes collègues à pouffé de rire mais ayant déja eu des problèmes avec la susceptibilité du personnage j'ai juste tiré la tête.

De façon générale, l'attitude de mon leader technique dans ce genre de situation est assez systématique et prévisible: repousser les décisions les plus délicates autant que possible. Lorsqu'il devient impossible de postposer la décision (parfois sous la pression du manager qui lui n'est pas développeur), il prend une décision de bourrin et l'impose au reste de l'équipe.

Dans ce cas ci, les problèmes les plus importants seront (je pense)
- la gestion de "fake foreign key" entre les différentes DB
- la nécessité pour le software de se connecter simultanément et alternativement à plusieurs DB
- le nombre de projets qui devront être créés. J'évalue plusieurs dizaines de projets qui pourront chacun, selon les décisions des utilisateurs, se décliner en dizaines de versions. Donc au total entre 50 et 1000 DB séparées sur un serveur dans la version de production (finale) du software !

Enfin des fois je ferais sans doute mieux de suivre les instructions de la hiérarchie sans me poser de questions... Le boulot ne peut apparamment pas être toujours super sympa.

[CinePhil]

J'évalue plusieurs dizaines de projets qui pourront chacun, selon les décisions des utilisateurs, se décliner en dizaines de versions. Donc au total entre 50 et 1000 DB séparées sur un serveur dans la version de production (finale) du software !

C'est du suicide !
A moins qu'il ne cherche des (faux) arguments pour faire changer son serveur ?

Enfin des fois je ferais sans doute mieux de suivre les instructions de la hiérarchie sans me poser de questions... Le boulot ne peut apparamment pas être toujours super sympa.

Si tu lui apportes des arguments solides et que tu les proclames suffisamment fort pour que d'autres les entendent également, il ne pourra pas s'aventurer dans une telle ineptie.
Au besoin, invite le sur Développez.com et notamment sur le blog de SQLPro pour lui apprendre ce que c'est qu'un SGBDR. Notamment cette partie là.
On sera plusieurs à pourvoir lui expliquer que ce qu'il envisage de faire est une connerie qui pourrait lui coûter son job.

Au fait, profites-en pour monter un schéma qui tient la route, éventuellement sur ton temps libre à la maison de manière à pouvoir te défendre au cas où... La période de crise actuelle n'est pas en faveur des petits jeunes qui contredisent les vieux de la vieille sans arguments.
Il faut que ton projet soit en béton.

[JPhi33]

CP = chef programmeur ?

Si je posais cette question sur le forum, c'était juste pour vérifier un truc: mon chef de projet est bien le seul à choisir [...]

CP = chef de projet


JPhi33

[L. Sierra]

C'est du suicide !
A moins qu'il ne cherche des (faux) arguments pour faire changer son serveur ?

Apparamment je ne suis pas le seul à trouver ce choix surprenant.

La période de crise actuelle n'est pas en faveur des petits jeunes qui contredisent les vieux de la vieille sans arguments

C'est exactement le problème. Je ne pense pas que ce soit une bonne idée de rentrer dans le tas en gueulant au scandale. Crise ou pas, la hiérarchie existe et il est de mise de respecter les décisions lorsqu'elles sont clairement arrêtées. De plus il n'y a personne dans la hiérarchie qui puisse vraiment juger de la faisabilité, car au dessus du leader de projet il n'y a que des managers qui ne sont pas experts en SGDB voire même en développement. Si mon leader technique risque sa place (est-ce vraiment le cas ?), moi je risque aussi de me décrédibiliser.

Donc si tu (ou n'importe quel forumeur) as des arguments précis à me fournir (genre au dessus de 100 DB sur un seul serveur le temps de réponse devient de l'ordre de plusieurs secondes) je pourrai peut être les soumettre au manager et lui proposer une discussion sur un ou deux points précis.

Sans argument précis et valable, je risque juste de fâcher encore un peu le leader technique (je crois que le rire et le silence qui ont suivi son annonce l'ont déja incommodé) et me faire rabrouer par les managers. A long terme si le projet part en vrille je ne suis pas officiellement responsable. En fait si je ne regarde que mon intérêt personnel, je fais mieux de me taire

[chaplin]

Pour un projet, quelle sera la table qui comportera le plus d'éléments et combien au maximum, à la louche.

En fonction de ce résulat, on peut arriver à des tables qui peuvent faire plusieurs milions de lignes. La centralisation des données à son lot d'avantages et d'inconvénients, ça se discute comme dirait l'autre. S'il faut faire de la maintenance, tous les utilisateurs seront concernés en cas de problème. Ensuite, des SGBDR capable de tenir des gros volumes de données restreint le choix aux doigts d'une main. Pour résumer, travailler avec des gros volumes de données demande beaucoup de rigueur au détriment de la souplesse à la fois technique et humain.

[L. Sierra]

Pour un projet, quelle sera la table qui comportera le plus d'éléments et combien au maximum, à la louche.

Je dirais quelques centaines. Ce sont des tables qui contiennent des informations assez simples, souvent des foreign keys ou des string (varchar) assez courtes. Il se peut que plusieurs tables contiennent quelques centaines de lignes. Disons 10 tables contenant entre 50 et 500 lignes, le reste moins de 50 lignes.

S'il faut faire de la maintenance, tous les utilisateurs seront concernés en cas de problème. [...] travailler avec des gros volumes de données demande beaucoup de rigueur au détriment de la souplesse à la fois technique et humain.

Les utilisateurs sans doute, moi je suis développeur (occasionnellement analyste, testeur etc). Comme je ne programme pas directement la couche qui attaque la DB en SQL, j'aurai au moins un tampon si jamais la DB devient ingérable. A vrai dire j'ai surtout peur pour ceux qui vont utiliser le soft. Au début tout ira bien, puis une fois qu'ils auront plein de projets et plein de versions, là ils tomberont sur les défaillances éventuelles . Ce jour là si ça se trouve je bosserai sur un autre projet

[chaplin]

Il y a un adage qui dit "vaut mieux prévenir que guérir". Il est sûr qu'une base de données centralisée serait idéale, mais dans la pratique, si le "responsable" de la BDD ou un DBA va mettre systématiquement son grain de sel sur les décisions, c'est un problème supplémentaire à gérer et parfois même un obstacle .