Discussion :

[teddyalbina]

Pour prendre part au débat, je dirais SQLpro à raison. Certes les ORM c'est bien pour coder rapidement mais on arrive vite au bout. Perso je suis encore étudiant mais pour l'entreprise ou je bosse j'ai du coder un site web avec asp.net/sql server 2008.

Comme ORM nous avons utilisés Linq to SQL (je connais bien entity framework aussi) et je dois dire que pour faire de la requête select et des jointures simples c'est vraiment top.

Mais pour les opérations sensibles, comme l’ajout d’articles, la gestion des clients, gestion des commandes etc.... j'ai vite trouvé les limites. Il y a une perte de control qui n'est pas acceptable sur ce qui ce passe au niveau de la db. J'ai donc utilisé des procédures stockées des fonctions pour toutes les requêtes sensible, avec les transactions qui vont bien et maintenant tout roule niquel c'est vraiment fiable.

En plus avec sql server 2008 les outils de debug sont fournit même pas besoin de lancer vst bref j'adore.

Pour le coup moi qui avait un peu laisser le SQL je m'y suis remis,n SQL c'est vraiment top et fun. J'essaie de me faire une vraie culture au niveau SGBDR.

[B.AF]

Pour prendre part au débat, je dirais SQLpro à raison. Certes les ORM c'est bien pour coder rapidement mais on arrive vite au bout. Perso je suis encore étudiant mais pour l'entreprise ou je bosse j'ai du coder un site web avec asp.net/sql server 2008.

Comme ORM nous avons utilisés Linq to SQL (je connais bien entity framework aussi) et je dois dire que pour faire de la requête select et des jointures simples c'est vraiment top.

Mais pour les opérations sensibles, comme l’ajout d’articles, la gestion des clients, gestion des commandes etc.... j'ai vite trouvé les limites. Il y a une perte de control qui n'est pas acceptable sur ce qui ce passe au niveau de la db. J'ai donc utilisé des procédures stockées des fonctions pour toutes les requêtes sensible, avec les transactions qui vont bien et maintenant tout roule niquel c'est vraiment fiable.

En plus avec sql server 2008 les outils de debug sont fournit même pas besoin de lancer vst bref j'adore.

Pour le coup moi qui avait un peu laisser le SQL je m'y suis remis,n SQL c'est vraiment top et fun. J'essaie de me faire une vraie culture au niveau SGBDR.

Ben c'est que tu n'as pas si bien compris.

Au contraire, les ORM ne fonctionnent que si et seulement si la base en dessous d'un point de vue relationnel est fiable.

Déjà rien que sur le design d'un table, de sa clef, et des indexes on peut voir des horreurs, alors dans les relations, faut voir que pour 90% des gens, c'est juste une flêche que tu dessines dans le shéma.

Le vrai pb de fond du stockage de données, c'est qu'aujourd'hui on génére du code.

Je me permets de citer cet extrait de la doc d'IBatis :

The best time to use a Data Mapper, like iBATIS, is when:

You do not have complete control over the database implementation, or want to continue to access a legacy database as it is being refactored.

You have database administrators or SQL gurus on the team.
The database is being used to model the problem domain, and the application's primary role is to help the client use the database model.

[SQLpro]

Dommage que je n'ai pas vue cette remarque de la doc d'Ibatis avant de finaliser mon article, car j'aurais pu l'intégrer !

A +

[B.AF]

Dommage que je n'ai pas vue cette remarque de la doc d'Ibatis avant de finaliser mon article, car j'aurais pu l'intégrer !

A +

Pourtant c'est ce qu'ils conseillent en début de documentation.
C'est ça qui me gêne. Tu as descendu en flamme des outils que tu ne connais pas en faisant l'amalgame produit / utilisation.

On peut faire des horreurs en c++, des merveilles en vb. La techno, sans intervention d'inteligence, ça ne sert à rien.