Discussion :

[SQLpro]

Lunatix dit :

justement, dans le web, le fait d'avoir a maitriser la conception des schémas est plutôt un handicap. Dans le monde du web ou il est nécessaire de relier des concepts, des entités simplement la rigidité des sgbdr n'est pas forcement bienvenue.

C'est à cause de la non maitrise de la conception des bases de données que l'on a tant de sites inexploitables. Les données étant ce qu'elles sont (des données) on a encore rien trouvé de mieux que les SGBD relationnels pour structurer les informations transactionnelles. Ce qui ne veut pas dire que certains SGBD non relationnels ne soient pas intéressant pour résoudre un problème précis.
Par exemple Google table n'est pas adapté à un site web d'e commerce !
Par exemple les modèles d'hypercubes ne sont pas adaptés à la facturation. Ces derniers sont intéressant pour le décisionnel et viennent à la suite d'une base relationnelle afin de compléter la structure de données déjà existante et pour résoudre une problématique précise : le forage de données.

Tant que l'on y est citons aussi les bases de données XML, Objet, deductives et multivaluées... Tiens on en parle tellement qu'il n'y a aucun forum en français sur ce sujet dans developpez.com !

A +

[jmguiche]

justement, dans le web, le fait d'avoir a maitriser la conception des schémas est plutôt un handicap. Dans le monde du web ou il est nécessaire de relier des concepts, des entités simplement la rigidité des sgbdr n'est pas forcement bienvenue.

D'après mon experience, c'est loin d'être vrai.
La méconnaissance des technologies base de données par des équipes de développement web aboutie à des projets

• trop chers en cout de développement (de 3 à 10 fois trop cher )
• et dotés de performances déplorables (jusqu'a 1000 fois plus lent pour des calculs, je ne parle même pas de full table scan).

Je ne suis pas le seul à l'avoir constaté.

De toute façon, maitriser quelque chose n'est jamais un handicap, même si ce n'est pas d'un usage immédiat (et dans ce cas, cela s'appele la cullture), cela permet d'avoir de la hauteur de vue. Il n'y a pas de savoir inutile. Sauf sous certains régimes qui pratiquent la censure et l'autodafé, mais c'est une autre histoire.

[ylarvor]

Personnellement, je dirais même que la conception web se compose à 80% de la bonne utilisation de la base de données.

Lorsque vous avez modéliser correctement votre base avec POWER AMC et générer un script.
Lorsque vous écrit des requêtes SQL optimisé donnant des résultats juste.

Il ne reste qu'à remplir des dataset et faire un peu d'ergonomie qui s'appuie généralement sur le travail d'un graphiste.

Toute l'intelligence du developpement web se trouve donc dans l'architecture et les accès aux données.

Sur des applications clients lourds, de gestion par exemple, il arrive parfois que la modélisation UML soit plus importante avec des couches métiers complexe...
MAIS dans le web, vous avez une interface trés lègère connecté une base de données qui fait le gros du travail.

Yann. Développeur ASP.NET

[jmguiche]

...Sur des applications clients lourds, de gestion par exemple, il arrive parfois que la modélisation UML soit plus importante avec des couches métiers complexe...
...

Tu devrais lire le lien que j'ai mis dans mon post précédent.
Il raconte des comparatifs d'application de gestion, les un développés avec un server d'appli abritant les regles de gestion, le "métier", les autres ou le server d'appli ne s'occupe de de construction de pages, les règles de gestion, le métier étant dans la base sous forme de procédures stockées.

C'est assez édifiant, et c'est tout à fait en accord avec ce que j'ai moi même constaté.

[Keihilin]

Plus sérieusement, à plus court terme, je pense que les SGBDR intégreront rapidement les fonctionnalités de serveurs d’applications.

Tendance déjà en cours avec l'intégration de Java dans Oracle et Sybase et de la CLR dans SQL Server...

A part ça, je ne m'attend pas à de grosses révolutions dans l'avenir.

Les BDD Objets répondent de manière élégantes à certaines problématiques, mais il arrive fatalement un moment ou les besoins en reporting oblige à migrer vers un modèle transactionnel afin de conserver de bonnes performances. Au final, la base objets tient le rôle d'outil de mapping O/R (c'est du vécu dans déjà 2 projets...).

Concernant l'emplacement de la logique métier :

Le dogmatisme est toujours source d'idiotie. Il faut savoir reconnaître les cas où il est justifié de placer de la logique métier dans la base de donnée et les cas ou ce n'est pas nécessaire.
Car n'oublions pas une chose; les différentes couches applicatives et les logiques métiers gérées par un beau domain d'objets ne sont pas un effet de mode. Un domaine objet bien pensé sera toujours plus facile à maintenir que des kilomètres de procédures stockées, aussi bien organisées soient-elles.

[SQLpro]

La méconnaissance des technologies base de données par des équipes de développement web aboutie à des projets

* trop chers en cout de développement (de 3 à 10 fois trop cher )
* et dotés de performances déplorables (jusqu'a 1000 fois plus lent pour des calculs, je ne parle même pas de full table scan).

Je ne suis pas le seul à l'avoir constaté.

J'y rajouterais mon expérience personnelle : mi juillet un client me contacte avec un projet de développement à terminer fin septembre... Toutes les SSII avaient évaluées ce projet à 6 mois homme. Nous avions juste un peu plus de 2 mois. Infaisable pour l'ensemble de ces SSII. J'ai relevé le défi. Nous avons travaillé avec un modèle hypernormalisé et à coup exclusivement de vues et procédures stockées : une vue, 3 procédures stockées par écran (INSERT, UPDATE, DELETE). Au bout de 3 semaines nous avons fait travailler un développeur pour les IHM. Il avait juste les définitions des vues et des IHM. L'assemblage à commencé au bout d'un mois et mi septembre 80% de l'application était écrite. Au 30 septembre 90% de l'application fonctionnait et avait été testé.
Cette application était destiné à gérer des contrat d'assurance pour le compte d'un des 3 premiers assureurs mondiaux et pour les travaux effectués par l'un des leader européen de l'énergie...

Bref, pas photo. Quand on sait développer avec une base de données et que l'on se repose sur sa logique en faisant le moins possible de ligne de code... ça paye !

A +

[orafrance]

j'ajouterai que c'est souvent (toujours ? ) plus payant de passer par des vues et procédures que par un outil de mapping

[Keihilin]

j'ajouterai que c'est souvent (toujours ? ) plus payant de passer par des vues et procédures que par un outil de mapping

ça dépend des cas...

Un outil de mapping intelligent permet quelques "économies". Là où en passant par une vue ou une proc tu vas devoir envoyer la totalité de ton objet pour une modification, avec du sql généré par un outil de mapping, tu peux te contenter d'envoyer uniquement les propriétés qui ont changé (impact faible je te l'accorde, mais quand même).

Autre cas de figure qui a posé problème pendant longtemps : passer une collection (tableau de données) en paramètre à une proc. Dans ce cas de figure, du code généré apportait un vrai plus.

[orafrance]

sauf que dans une base de données j'vois pas bien l'intérêt de passer un tableau quand une sélection de table suffit

[Keihilin]

sauf que dans une base de données j'vois pas bien l'intérêt de passer un tableau quand une sélection de table suffit

euhhh, je te laisse te relire 3 ou 4 fois avant de tenter une réponse...

[orafrance]

je maintiens... un tableau contient probablement le résultat d'une requéte... donc une vue remplace facilement l'usage d'un tableau

[Keihilin]

je maintiens... un tableau contient probablement le résultat d'une requéte...

Ben non justement. On parle de mapping (donc de données qui peuvent provenir d'une autre couche logicielle) et de paramètres d'une procédure stockées.

L'exemple le plus naïf qui me vient est de vouloir passer une série de valeurs à une proc pour alimenter une clause WHERE ... IN ([..,..]).

On a donc un nombre de paramètres variable et la seul façon de passer ça à une proc est (ou plutôt était) de déclarer le paramètre en varchar(500) (ou plus) et d'utiliser du sql dynamique...bref, moyennement propre.

[jmguiche]

...
Bref, pas photo. Quand on sait développer avec une base de données et que l'on se repose sur sa logique en faisant le moins possible de ligne de code... ça paye !

A +

C'est marrant, je pensais un peu me faire allumer en tenant de tel propos.
Le dogme de l'objet, du server d'application qui doit s'occuper du "métier" et autre JEE est tellement puissant, les personnes sachant utiliser une base de données devenu tellement rares, les architecture à la dubout pour des fonctionnalités simplissimes à metre en oeuvre avec les SGBD promues "état de l'art" tellement systematiques, les kilomètres de de C# et de java pour faire l'équivalent de 100 ligne de PL (ou de transac, pour te faire plaisir) tellement encombrant que j'ai l'impression de temps en temps d'être un extra terrestre.


Merci, je me sent moins seul.

[Keihilin]

Le dogme de l'objet, du server d'application qui doit s'occuper du "métier" et autre JEE est tellement puissant

Il faudrait quand même analyser les raisons pour lesquelles ce "dogme" s'est imposé.
Quand on y refléchit 5mn, il est légitime de se demander pourquoi l'OO et les serveurs d'applications ont émergé face aux BDD qui ont pourtant de nombreux atouts en informatique d'entreprise qui consiste quand même majoritairement à manipuler des données.

Un des points tient, à mon avis, à la faiblesse des langages T-SQL ou PL/SQL.
Au fur et à mesure de l'augmentation de la complexité des traitements, les avantages des langages OO deviennent de plus en plus évidents. Comme dit précedemment, une logique métier complexe gérée par un domaine objet bien conçu sera toujours plus souple et maintenable grâce aux mécanismes OO (genre substitution) que des kilomètres de procédures avec des centaines de IF THEN ELSE.

[jmguiche]

Il faudrait quand même analyser les raisons pour lesquelles ce "dogme" s'est imposé.
Quand on y refléchit 5mn, il est légitime de se demander pourquoi l'OO et les serveurs d'applications ont émergé face aux BDD qui ont pourtant de nombreux atouts en informatique d'entreprise qui consiste quand même majoritairement à manipuler des données.

Un des points tient, à mon avis, à la faiblesse des langages T-SQL ou PL/SQL.
Au fur et à mesure de l'augmentation de la complexité des traitements, les avantages des langages OO deviennent de plus en plus évidents. Comme dit précedemment, une logique métier complexe gérée par un domaine objet bien conçu sera toujours plus souple et maintenable grâce aux mécanismes OO (genre substitution) que des kilomètres de procédures avec des centaines de IF THEN ELSE.

C'est le discours que tout le monde tient.

Je dirige des projets, qqfois, je choisis les technos, qqfois pas.
Quand je connais les technos j'interviens techniquement, sinon je prend des experts (en interne, en SSII, et même souvent chez les éditeurs).

D'apres mon experience, de multiples projets database centric et d'autres "orientés objets" (C++, JAVA, .NET avec des équipes différentes), il n'y a pas photo et plus le sujet est complexe, plus l'approche objet est catastrophique, que cela soit en cout de dévellopement, en cout de maintenance, en perf, en nombre de bug (normal, il y a plus de code), etc...

Ce n'est que mon experience, une experience de vécu des 2 mondes.


Le dogme s'est imposé de la même façon que le C à remplacé COBOL pour faire de la gestion, pour de mauvaises raisons. L'informatique de gestion a un complexe vis à vis des gens qui font des choses plus technique (outils, OS, réseau...) et souhaite utiliser les mêmes outils.
Pourtant, un outil conçu pour faire du réseau, un OS ou un gestionnaire d'interface graphique n'est pas forcement adapté à la gestion.(ou la, je vais m'en prendre ! )

[orafrance]

Quand on y refléchit 5mn, il est légitime de se demander pourquoi l'OO et les serveurs d'applications ont émergé face aux BDD qui ont pourtant de nombreux atouts en informatique d'entreprise qui consiste quand même majoritairement à manipuler des données.

Tout simplement parce que le client léger remplace le client lourd et que le java c'est imposé comme le langage le plus adapté pour développer les IHM. Ca n'a rien à voir avec la BDD, c'est l'IHM qui impose ses orientations techniques.

Et si les BDD se mettent à intégrer l'objet c'est, je pense, surtout pour éviter les outils de mapping qui sont une catastrophe pour la modélisation et les perfs en général.

Comme dit précedemment, une logique métier complexe gérée par un domaine objet bien conçu sera toujours plus souple et maintenable grâce aux mécanismes OO (genre substitution) que des kilomètres de procédures avec des centaines de IF THEN ELSE.

c'est plus souple de modifier un objet plutôt qu'ajouter une colonne à une table... là j'ai de gros doute parce que quand je vois les usines à gaz développer avec des metadatas immenses, ça ne me donne pas l'impression d'une maintenabilité accrue.

Après, j'suis peut-être tombé que sur des dévs incompétents... c'est pas impossible non plus

[Keihilin]

D'apres mon experience, de multiples projets database centric et d'autres "orientés objets" (C++, JAVA, .NET avec des équipes différentes), il n'y a pas photo et plus le sujet est complexe, plus l'approche objet est catastrophique, que cela soit en cout de dévellopement, en cout de maintenance, en perf, en nombre de bug (normal, il y a plus de code), etc...

Observation étonnantes, hormis concernant les perfs.

Je ne peux que supposer que tu es tombé sur le genre d'équipes que je croise régulièrement : "Oui oui, on est des spécialistes .Net, on fait du VB.Net et on connait super bien l'OO ! UML ? C'est un truc qui vole non ?".
En gros, des gens qui croient savoir parce qu'ils ont utilisés 2 ou 3 fois avec succès un wizard sous Visual Studio.
Que ce soit dans le monde OO ou dans le monde BDD, il y a de plus en plus de développeurs qui n'ont pas la moindre idée de ce qu'il se passe réellement derrière, habitués qu'ils sont d'avoir 90% du travail caché/mâché par divers assistants et fonctionnalités de très haut niveau.

Je suis particulièrement surpris par tes observations sur les coûts de maintenance et le nombre de bugs.

Soit je suis complètement à côté de la plaque et certains mécanismes hyper puissants de T-SQL ou PL/SQL m'ont complètement échapé (ce dont je me permets de douter quand même), soit des problématiques complexes seront souvent avantageusement gérées (en terme de souplesse et de facilité de maintenance) par une hiérarchie d'objets bien pensés plutôt que par des cascades de IF.

Concernant les bugs, il est tout d'abord faux de penser que OO = plus de code, et ensuite les environnement comme Java ou .Net sont pourvus d'outils de tests unitaires et de couverture de code qui augmentent la fiabilité. Il est difficile, et parfois impossible, d'utiliser des outils équivalents sur des bases de données.

Entendons-nous bien : je ne suis de loin pas dogmatique ou sectaire. Je ne suis pas un acharné des modèles objets et des analyses top-down à tout prix mais l'OO n'est pas un effet de mode inventé pour calmer les complexes des informaticiens de gestion...

[Keihilin]

c'est plus souple de modifier un objet plutôt qu'ajouter une colonne à une table...

Je ne vois pas le rapport.

La logique métier ce n'est pas une façon d'organiser les données, c'est une façon de les manipuler.
DOnc une règle de gestion qui se modifie en ajoutant juste une colonne à une table ?

[orafrance]

DOnc une règle de gestion qui se modifie en ajoutant juste une colonne à une table ?

bah oui

Tiens j'aimerai bien ajouter la date de naissance du client pour m'envoyer un mail quand c'est son anniversaire et ainsi faire un geste auprès de lui...

[Keihilin]

Ah ok...

Et tu ajoutes juste une colonne "BIRTHDATE" dans ta table CLIENTS et la BDD comprend toute seule ce que tu veux et se charge d'envoyer un mail et de commander une boîte de chocolat.

Soit je suis complètement à côté de la plaque et certains mécanismes hyper puissants de T-SQL ou PL/SQL m'ont complètement échapé (ce dont je me permets de douter quand même)

Je reviens sur ce que j'ai dit, j'ai largement sous-estimé la puissance des SGBDR actuels...