Conception : L'approche "Model First" n'est-elle pas plus saine que l'ancestrale approche "Schema First"

Pour moi, cela fait longtemps que c'est la base de ma pensée...

Dans 99.999999% des cas que j'ai vu, utiliser une SGBD était tout simplement un "trip" ou un à-priori d'informaticiens ou de boîtes...

Dans la pratique, à quelques (très rares) exceptions près, cela complique très nettement le choses, sans parler des coûts qui explosent...

Je ne suis pas contre à priori, je suis contre l'utilisation d'un bulldozer pour écraser une mouche...

Et en effet, de ce que je vois depuis une 15 aine d'années avec l'OO, sa modélisation, et les possibilités offertes par des outils/langages.. comme SQL, je pense fondamentalement que dans le principe il y a un bug....

Quand on demande à faire une opération complexe, c'est une opération métier. Cela devrait donc être à la couche métier de la faire. Et de plus, comme c'est métier, cela devrait être indépendant de la manière dont les données sont stockées/gérées, et donc indépendant de la BD..

Or je ne vois apparaître que de plus en plus de liens, et de plus en plus d'imbrication de la BD avec les données et le métier...

Pour moi, une bonne application portable et indépendante devrait considérer à la base être répartie et multi-BD, et donc indépendante de SQL etc (avec par exemple certaines données sous Oracle, d'autres sous Access, d'autres dans des fichiers textes etc etc..).

UNIQUEMENT à cette condition on aurait alors une vraie analyse, et une vraie séparation et indépendance...

Mais visiblement les forces du marketing et des modes sont plus fortes que le bon sens

Sans parler des problèmes de perfomances, où pour accéder à une donnée il faut passer à travers 250 tables différentes..

Ca, ca fait plaisir à lire !

Bien qu'idéaliste, je partage cette conviction. Cependant dans les cas concrets et sous le joug de fortes contraintes de temps, on s'assoit vite sur ces bons principes.

De quelle mode parles-tu ? Il me semble que la mode justement est aux architectures en couche avec une segmentation claire des responsabilités, et une indépendance marquée entre elle (couplage relaché).

C'est intéressant, car ce que toi et Souviron soutenez est exactement l'approche fustigée par SQLPro dans son article et sur ce même forum.

A nous autres non expert de trouver notre vérité...

C'est exactement ce que je me disais aussi.

Les bases de ces deux approches sont parfaitement recevables.

Dans le cas du modèle OO drivant le modèle relationnel, quel interet à passer sur un SGBDR ? pourquoi n'utilisez vous pas un SGBDOO cela éviterai les couches ORM et vous auriez une vraie gestion OO .

Pour la partie bases de données épaisses j'accroche un peu plus car combien d'applications sont développées avec les dernières technologies (dot, java,...) tout en gardant le modèle d'origine d'il y a quelques années (qu'il soit bon ou mauvais) ?

Je ne sais pas, de ce que je vois sur les forums ici et là...

Que ce soit en développements Web, sur le forum Conception, ou sur le forum BD...

Je trouve les schémas, modélisations, etc etc, et BDs très très très fortement liées (via la BD, via un outil)..

Et l'utilisation d'UML ou de MCD comme des Dieux en fait partie...

Ce n'est pas du tout ce que l'on essaie de faire passer comme message dans Conception!! Au contraire!
On y parle d'orthogonalité, de forte cohésion, faible couplage, séparation des responsabilités...
La persistance (mémoire) de l'appli est gérée par un SGDBr. On fait un modèle ad hoc. Pour moi c'est encore 1 MLD.
Et si la cible est 1 SGBD00 c'est un DC UML spécialisé.
Le métier (l'intelligence) c'est un autre modèle (DC UML). La couche métier n'a pas a savoir comment les données sont persistées. Elle délègue de façon transparente à une couche service (DAL/DAO)
La couche service de persistance c'est avec un framework. Hibernate par exemple parce que je pense que c'est le plus évolué (mais d'autres en préfèreront un autre et auront aussi raison).
Plus les 2 modèles à mapper seront propres, plus le mapping auto sera de bonne qualité. Mai pour l'instant le meilleur ''mapper'' reste le dev. Et il ne faut pas s'imaginer que HB8 est une baguette magique qui va corriger les erreurs de conception et faire un bon travail à partir de bases cochonnées.
On peut faire du boulot trés propre et trés fin avec un framework. Mais il ne sufit pas de cliquer sur 2 boutons pour générer un modèle générique et ensuite dire que l'outil fait de la merde. Ou à l'inverse bidouiller dans le mapping sans se poser de question sur l'intelligence de ce qu'on fait pour corriger des erreurs ou des manques dans les modèles données ou métier. Ca nécessite un minimum de compétences.

Dans ceux ou je travaille, c'est 99,9% obligatoire. Mais c'est du à un domaine différent sans doute (info de gestion)

. Tu t'es déjà battu avec les pointeurs d'une appli en c qui gère les objets dans un base oo ?
XML c'est un caviar à faire.

Mais elle n'a même pas à savoir ce que c'est que la persistence !!!!

Par contre, la BD n'a rien à savoir de ce qu'on fait avec les données. Elles est purement fournisseuse...

Or je vois (et je suis désolé, cela figure beaucoup dans ce que je vois dans le forum Conception) des modèles où on applique des "join", des "where", etc etc..

Et, qui plus est, où on introduit (dans du code Java, Php, C++, ou n'importe quoi) des requêtes SQL (ou mysql, mais c'est strictement pareil), dans du code d'IHM, dans du code métier, etc etc...

La combinaison des 2 effets me paraît catastrophique...

C'est tout.