Discussion :

[molarisapa]

Bonjour

Je dois commencer un nouveau projet de zéro.

Après l'étude du besoin, j'ai réalisé la modélisation relationnelle MCD de ma base.

Maintenant, je vais développer ma couche modèle mais par où commencer? Quel est l'usage le plus standard?

- Est-ce qu'il faut que je crée ma base SQL, puis que j'auto-génère mes classes Java de mapping avec un wizard?

- Est-ce que je dois implémenter mes classes Java puis j'auto-génère les scripts SQL de création de ma base (voir même je laisse la création de la base au premier déploiement)?

Merci

[Jimmy_]

Bonjour,

Faire un MCD c'est bien, mais as-tu déjà fais un MOT ou un MCT ?
Car en pratique si tu calques ton MCD pour en faire des tables (générés ou pas ...) suivant les traitements que tu vas faire ça ne va pas donner le même résultat.

Pour faire simple, si ton application fait plutôt de la synthèse, tu as intérêt a retravailler tes tables pour éviter d'avoir 50 jointures à faire dans tes ordres.
Si par contre ton application fait plus dans la collecte d'information, effectivement ça sera plus simple avec plein de table.
Bref a toi de voir ...

Bref il n'y a pas d'outil magique, le tout généré c'est bien en théorie, en pratique ... c'est une autre paire de manche.

Bon courage,

[OButterlin]

Pour faire simple, si ton application fait plutôt de la synthèse, tu as intérêt a retravailler tes tables pour éviter d'avoir 50 jointures à faire dans tes ordres.
Si par contre ton application fait plus dans la collecte d'information, effectivement ça sera plus simple avec plein de table.
Bref a toi de voir ...

Le problème n'est pas là, c'est plus un problème d'optimisation.
Le nombre de tables est lié au modèle relationnel, pas à son usage.
Pour optimiser les traitements, on peut créer des vues...

Le pire, c'est la redondance d'informations...

[DevServlet]

Avec quel outil as tu fait ton MCD?

[tchize_]

Bonjour,

Faire un MCD c'est bien, mais as-tu déjà fais un MOT ou un MCT ?

On pourrais avoir la traduction des ces acronymes en français courant de pas-France?

Blague à part, personellement, si t'as aucune données legacy qui traine, je partirais sur un modèle objet que je fais évoluer au fur et à mesure des besoin clients et je laisse l'ORM se débrouiller derrière comme il le fait bien

[OButterlin]

Il y a 2 approches quand on part de rien :

- faire le modèle objet et déduire et créer les tables (quand on n'a pas d'ORM pour le faire)
- faire un MCD et créer l'application à partir de là

Si la base de données ne sert qu'à cette application, la première méthode est très certainement meilleure, sinon, je pense qu'il vaut mieux se concentrer sur les données.

[DevServlet]

Pour la petite expérience que j'ai, quand on conçoit une base de donnée, elle est censée coller avec un besoin métier bien précis, et qui dit métier pense forcement que la base soit plus tard attaquée par plusieurs applications, je veux en fait dire que je ne suis pas très fan des base générées par le modèle objet, je serai lui, je partirai d'un modèle conceptuel, ensuite un modèle physique qui génèrerait un script de script de création de la base, ceci indépendamment des couches qui viendront taper dessus, donc plutôt la 2eme approche de OButterlin. après t'as des framework java qui vont du retro en te générant le modèle entité correspondant, même si derrière faut quand même retoucher ces classes générées.

[tchize_]

Pour la petite expérience que j'ai, quand on conçoit une base de donnée, elle est censée coller avec un besoin métier bien précis, et qui dit métier pense forcement que la base soit plus tard attaquée par plusieurs applications,

Pour mon expérience, cela est très théorique: Dans 90% des applications BD que j'ai conçue jusqu'à présent, même si théoriquement la bd est attaquable par d'autres applis, en pratique ce n'est jamais le cas. Le besoin d'une deuxième application sur ces données n'est jamais arrivé. Perdre du temps à faire un modèle de base de donnée et se casser la tête après à le convertir en objet et donc à refaire le boulot de l'ORM, gérer le fait que plusieurs applications peuvent accéder aux données simultanément (et donc désactiver l'avantage de performances du chache de second niveau) est souvent un long travail inutile.

Et pour les application où la BD est effectivement réutilisée: dans la plupart des cas, c'est en réutilisant le même ORM et les mêmes modules codés en java.

De plus, les tables générées par l'ORM sont loin d'être incompréhensible ou hors normes. Ce n'est pas difficile de faire d'autres applis qui l'utilisent.

Enfin, croire que la base de donnée, c'est le métier, c'est faux. Aujourd'hui c'est ton application le métier, la base n'est qu'un support à ce métier, elle doit s'y plier. On est plus à l'époque où les application sur DB se contentaient d'appeler des procédure enregistrées ou des vues pour juste les afficher. Aujourd'hui, une grande partie de la logique métier se trouve du coté de l'application.


Maintenant, chaque application est différente, on est pas à la place de molarisapa pour décider . Je dis juste que passer du temps à prévoir des choses qui sont loin d'être certaines, ca a tendance souvent à augmenter inutilement les temps de dev. On bon code bien propre et raisonnablement évolutif (dans les règles de l'art on va dire) mais qui ne fait que le nécessaire est souvent bien plus rentable sur le court et le long terme.

[Jimmy_]

On pourrais avoir la traduction des ces acronymes en français courant de pas-France?

C'est du Meurise,
MCD : Modèle Conceptuel de données.
MCT : Modèle Conceptuel de traitement.
et MOT tu montes d'un niveau c'est le Modèle Organisationnel de Traitement.

Ces modèles permettent surtout à une appli de synthèse de ne pas faire 50 jointures dans ses ordres SQL et de se retrouver avec des temps de réponse tout pourri.

Le problème n'est pas là, c'est plus un problème d'optimisation.

Justement concevoir sa base sans connaitre les traitements que l'on va faire dessus conduit parfois à la catastrophe et ce n'est pas hibernate qui va résoudre le problème.
On parle bien d'optimisation sur des grosses bases de données. Quand l'explain plan Oracle, te donne des Table Space Scan sur 50% de tes ordres, soit tu pleures en appelant un DBA pour avoir plus de place dans ton TS pour les index, soit tu comprends que tu as tout faux car tu as fait trop de jointures et que dénormaliser ton modèle était la solution la plus efficace.

[OButterlin]

On parle bien d'optimisation sur des grosses bases de données. Quand l'explain plan Oracle, te donne des Table Space Scan sur 50% de tes ordres, soit tu pleures en appelant un DBA pour avoir plus de place dans ton TS pour les index, soit tu comprends que tu as tout faux car tu as fait trop de jointures et que dénormaliser ton modèle était la solution la plus efficace.

C'est pas de chance, tu bosses avec Oracle

blague à part, les vues sont là pour ça également...

Si vraiment on a besoin de données "compilées", on peut passer par une base multidimensionnelle alimentée par exemple par trigger...

[Jimmy_]

Les vues fonctionnent avec des jointures de toute manière, donc tes perfs seront identiques. Les triggers pour alimenter une autre table compilée oui, c'est une solution.

Pour comprendre voici un exemple simplifié que j'ai rencontré :

Alors prenons par exemple une appli de contrôle d'opération de paiement dans une grande chaine de magasin.
Il y a disons 50000 opérations/jours avec un historique de 5 ans, soit environ 63M d'opérations. 2M de références. 250 magasins. 1M de clients.

Le contrôleur doit avec sa belle appli J2EE faire des recherches par date et par magasin.

Tu dois afficher : l'opération, la référence, le magasin et le client. Bref joindre toutes tes tables avec des critères pas très discriminant.
Puisque le facteur de 250 pour les magasins et pour une date c'est un peu mieux environ 2000 pour un produit cartésien de l'ordre de 1.10^21

Bref tu exploses tout dès que l'utilisateur clique sur son bouton de recherche.


Alors quelle est la solution ? Faire de belles tables : clients, opérations, magasins et référence ? ou ajouter une table qui synthétise les lignes de contrôle avec toutes les infos nécessaires ? Et ça c'est pas le MCD qui te le dit, mais bien l'analyse du traitement qui doit être fait, donc MCT et MOT.