A partir de mon MCD, par où commencer ? Le SQL ou le Java ?

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

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,

Citation:

---

Envoyé par Jimmy_

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...

Avec quel outil as tu fait ton MCD?

Citation:

---

Envoyé par Jimmy_

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 :)

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.

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.

Citation:

---

Envoyé par 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,

---

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 :mouarf:. 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.

Citation:

---

Envoyé par tchize_

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.

---

Justement j'ai fait plus d'un projet où les bases étaient partagées entre des interfaces java et des interfaces php. Et de manière générale (pour ce qui est de ma propre expérience) l'existant en début d'un projet c'est la base de données à laquelle doivent se conformer les appli devant l'attaquer et non l'inverse. Il faut sortir un peu du monde java et réorienter son analyse de manière plus généraliste :mouarf:.
Enfin bref on a présenté les différents solutions à @molarisapa, charge à lui maintenant en fonction de son besoin de tirer le meilleur.

Oui, mais là on parle bien d'un projet ou la DB n'existe pas encore :). Si la DB existe déjà, en général, je recommande de ne même pas utiliser hibernate, ca ne marche en général pas bien avec les base de données "legacy" car ça exige certaines structures qui n'y sont pas nécessairement présentes. Et contourner leur absence coute plus de temps en général que ce qu'on gagne à utiliser hibernate

Citation:

---

Envoyé par tchize_

... avec les base de données "legacy" car ça exige certaines structures qui n'y sont pas nécessairement présentes...

---

C'est quoi le problème au juste ?
Et tu entends quoi par bd "legacy" ?
(c'est pas toi qui râlait contre MOT, MCT ? :mrgreen:)

legacy = héritage. Donc une base de donnée dont tu hérite, avec sa structure de tables, et tu peux rien y changer. C'est en général là que tu trouve des subtilités que hibernate digère pas bien mais que l'auteur de la DB avait trouvé une bonne idée de mette en place.

Dans la catégorie des trucs que hibernate digère pas toujours bien:

Une table sans primary key
Une table avec un primary key qui doit être un nombre strictement croissant et sans "trous" :aie:
Une données répartie sur plusieurs table (ex: tous les 1er du mois à minuit on prend le contenu de la table et on le transfère dans un table portant le même nom mais avec l'année et le mois derrière)

Citation:

---

Envoyé par tchize_

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.

Citation:

---

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.

Citation:

---

Envoyé par Jimmy_

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 :mouarf:

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...

Citation:

---

Envoyé par tchize_

Dans la catégorie des trucs que hibernate digère pas toujours bien:

1) Une table sans primary key
2) Une table avec un primary key qui doit être un nombre strictement croissant et sans "trous" :aie:
3) Une données répartie sur plusieurs table (ex: tous les 1er du mois à minuit on prend le contenu de la table et on le transfère dans un table portant le même nom mais avec l'année et le mois derrière)

---

1) oui, c'est pas terrible, encore que ça marche...
2) on peut passer par une sequence
3) oui, là, je ne vois pas de solution

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.

Citation:

---

Envoyé par OButterlin

2) on peut passer par une sequence

---

Une séquence oracle, ca crée des trous. Si la demande business derrière c'est numéros continus et croissant, y a pas le choix, t'es bon pour sortir le merdier du générateur custom d'hibernate :mouarf:

Citation:

---

Envoyé par Jimmy_

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

---

C'est surtout parce que, en général, les DB gèrent très mal les champs de date. Si la recherche par date est importante, il est préférable d'ajouter une colonne varchar avec la date écrite dedans.

construisez une table de plusieurs millions d'entrée avec entre autre une colonne type timestamp et une colonne type entier. Indexez tout ça sur ces deux colonnes.

Faites une recherche pour avoir tout ce qui correspond à la date du 23/01/2011.
Faites une recherche pour avoir tout ce qui correspond à l'entier entre 3 et 15.

comparez les perfs. J'admet que les jointure sont un problème, mais la DB est censée filtrer avant de faire la jointure. Quand à hibernate, il fera même pas les jointures donc c'est pas vraiment un problème pour lui :)



De toutes façons, beaucoup de grosse banque de données aujourd'hui sont occupée de dé normalisez leurs table voir carrément d'abandonner le format relationnel.

Citation:

---

Envoyé par 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.

---

Sur DB2 en tout cas, on peut créer des vues qui seront maintenues en temps réel.
Lorsqu'on fait une requête sur la vue, il ne reconstruit pas le chemin d'accès, il existe déjà et est à niveau.

pareil sur oracle, une requete tordue que j'ai du faire il y a quelque temps mettait 15 secondes à s'exécuter. La vue équivalente mettais 15 seconde à s'exécuter et le requete sur la vue quelques milli secondes.

Tu prends le coût de maintenance de la vue en temps réel sur chaque insert/delete/update.
A l'époque on a fait un batch de nuit pour que ce soit transparent, le contrôleur n'ayant pas besoin des données du jour.

Mais bon il faut voir au cas par cas selon l'utilisation.

Merci à tous pour vos aides.

J'ai eu plutôt l'habitude de travailler sur des applications où la base de données avait "pleins pouvoir" en abordant une place centrale et cruciale

Outre son rôle légitime de stockage de données, d'index, et son pouvoir exécutif à travers la panoplie de requêtes, elle avait aussi :

• un pouvoir de fonctionnalités métiers à travers des procédures stockées et distribuées
• un pouvoir d'adaptation et de pilotage à travers des vues
• un pouvoir conditionnelle à travers des triggers

J'ai bien aimé la citation de tchize

Citation:

---

Envoyé par tchize_

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.

---

Pour ce nouveau projet, je vais donc penser et concevoir mon système Métier autrement et le modéliser avant tout à travers les Objets/Héritage Java. Je vais aborder la SGBD comme un support à ce Métier Java.

Dans l'idéal même, ça serait de ne pas me projeter sur le support de données en me disant :
"En local, je vais développer sur du stockage en fichier xml. Mais peut-être qu'ensuite cela sera une sgbd MySql ou Postgres. Mais qu'importe, je me concentre sur ma couche métier Hibernate, le reste suivra naturellement"

(bien sur, je peux me permettre de penser comme cela, car au final, il n'y aura que 8 à 9 tables avec max 1000 enregistrements...)