Discussion :

[mermich]

il semble finalement plus efficace d'exporter les entités métiers et leurs règles sous formes de Vues et de Procédures Stockées

En terme de perf oui (sans doute), en terme de cout de devs non.

et de se servir du backend UNIQUEMENT pour faire appel à ces "objets". Y a-t-il des "opérations métiers" qui ne doivent pas être gérés par le SGBD? L'unique exemple qui me vient en tête sont des opérations scientifiques.

Logique recusive, mise en cache, gestion des exptions, utilisation de lib tierce, api tierce, gestion des logs, threads, il y a enormement de chose qui manquent ou sont ingerables pour un dev moyen cote bdd. Un dba va sans doute pouvoir le faire, mais a quel prix financier.

Si c'est le cas, cela implique que l'industrie actuelle est en décadence, compte tenu du fait que le dénie de la qualité et de l'importance des BDDs relationnelles soit devenu un VRAI culte(dont je faisais partie).

Des lors qu'une personne a une certaine expertise dans un domaine elle essaie de valoriser cette expertise, donc de defendre le domaine.

En outre, comment gérez-vous l'évolution du modèle conceptuel de données au fil du temps?
En effet, l'une des cause du l'abandon du relationnel est son apparente rigidité, ou plus concrètement l'exigence d'avoir un modèle parfait d'entrée de jeu. Que se passe-t-il concrètement lorsque:
- j'ai une table Client, avec pleins d'attributs.
- et je me rends compte qu'il faut rajouter un autre attribut?
- aujourd'hui, ce genre d'opération génère de la frustration chez les développeurs comme moi, car on a l'impression d'être "sale" en créant une table pour le nouvel attribut, ou même en mettant à jour la table Client, car cela bouscule les fonctions logiques métiers côté backend.

Le probleme reste entier cote code ou cote bdd si tu ajoute une propriete a ta classe il va falloir changer egalement pas mal de choses.

à quel point les optimisations statistiques faites par les SGBD sont-elles fiables?

Il peut y avoir des gains de perf notable si tu denormalises certaines tables mais c'est une tache pas si evidente.

En termes de CI/CD, comment procédez-vous? Utilisez vous les outils de migrations des librairies(builder SQL) que vous injectez dans le pipeline de déploiement? Ou bien procédez-vous autrement?

Il n'existe que je sache rien d'integre au cycle CI/DI donc migrations a la main. Le soucis est le meme pour les test unitaires.


Enfin dernier point, comment fait-tu pour versionner ta bdd, et travailler en equipe efficacement ?

[CinePhil]

comme le font les méthodes de classes qui délivrent des listes en sortie, genre public static function getListeCouleurs()

Si demain par exemple, tu as besoin de la liste des couleurs mais triée par ordre décroissant et limitée qu'au dix premières couleurs, tu vas faire comment ? Recréer une nouvelle ressource ?

1) Je donnais cet exemple fictif de méthode de classe (getListeCouleurs) parce que ça peut ne pas être une liste issue d'une BDD s'il y a très peu de couleurs disponibles.
Dans la pratique et pour le moment, les tables simples (typiquement les tables de référence du genre tr_civilite_civ (civ_id, civ_abreviation, civ_libelle, civ_ordre)), je ne fais pas de vue pour les interroger ; je trouve ça superflu parce que la structure d'une telle table est typique et a une probabilité assez faible d'être modifiée un jour (et on verra les modifs à ce moment là). Ma classe modèle Civilite interroge donc directement la table.

2) Si un programme interroge une vue, il y a donc quelque part une requête SQL qui fonctionne comme si elle interrogeait une table :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT les, colonnes
FROM la_vue
WHERE [la condition éventuelle]
ORDER BY [l'ordre demandé éventuel]

Je peux donc créer une méthode getListeCouleurs($tri = null, $limit = 'ASC') comme je le ferais pour une table... ou modifier la méthode précédemment créée puisque ta phrase commence par "si demain...".

[escartefigue]

En outre, comment gérez-vous l'évolution du modèle conceptuel de données au fil du temps?
En effet, l'une des cause du l'abandon du relationnel est son apparente rigidité, ou plus concrètement l'exigence d'avoir un modèle parfait d'entrée de jeu. Que se passe-t-il concrètement lorsque:
- j'ai une table Client, avec pleins d'attributs.
- et je me rends compte qu'il faut rajouter un autre attribut?
- aujourd'hui, ce genre d'opération génère de la frustration chez les développeurs comme moi, car on a l'impression d'être "sale" en créant une table pour le nouvel attribut, ou même en mettant à jour la table Client, car cela bouscule les fonctions logiques métiers côté backend.

Le nouvel attribut doit s'ajouter dans la table et on crée une nouvelle vue sur cette table
Ainsi, les traitements existants qui n'ont pas besoin de la nouvelle colonne continuent d'utiliser les vues existantes et ceux qui ont besoin de la nouvelle colonne utilisent la nouvelle vue
Exception : la nouvelle colonne est un BLOB ou autre objet très volumineux (image, vidéo) et sa présence est facultative (colonne "nullable"), il est préférable de créer une autre table, dont l'identifiant primaire sera le même que celui de la table client.

[Sodium]

Des lors qu'une personne a une certaine expertise dans un domaine elle essaie de valoriser cette expertise, donc de defendre le domaine.

C'est exactement ça : on ne va pas utiliser un programme qui fait ça tout seul (même si un peu moins bien) car sinon ça veut dire que je suis moins indispensable et que ma paie est moins justifiée.

On est purement dans l'intérêt personnel plutôt que dans l’intérêt collectif.

Aujourd'hui, n'importe qui possédant un minimum de connaissance en informatique peut créer son site avec Wordpress ou son e-commerce avec Prestashop. Les devs viennent ensuite pleurer parce que ça ne sera pas aussi bien fait et performant que s'ils l'avaient fait (en facturant quelques dizaines / centaines d'heures)... ben oui mais ça répond à un besoin réel...

Le nouvel attribut doit s'ajouter dans la table et on crée une nouvelle vue sur cette table
Ainsi, les traitements existants qui n'ont pas besoin de la nouvelle colonne continuent d'utiliser les vues existantes et ceux qui ont besoin de la nouvelle colonne utilisent la nouvelle vue

Ca sent bon l'application maintenable à long terme ça

Créer une nouvelle vue sans supprimer l'ancienne à chaque champ ajouté dans une table... les db admins vivent vraiment dans leur monde à eux

[CinePhil]

Ah bon ?
Ta vue, elle récupère TOUTES les données possibles et imaginables, et dans le code, tu n'as qu'à implémenter :
- La liste des colonnes à récupérer
- Quelques conditions d'égalité pour implémenter les filtres
- Une jolie clause order by

Yep, donc une vue obèse, qui répond à UN besoin à UN instant T, impossible à maintenir

Non, une vue optimisée pour un panel de besoins définis.
Une vue modifiable côté SQL si la structure de la BDD change mais qui donnera les mêmes résultats à l'application qui n'aura pas à être modifiée, même si la vue est utilisée par plusieurs morceaux de programmes ou plusieurs applications.
J'ai besoin de cette vue avec d'autres informations ?
=> Je fais une nouvelle vue pour ce besoin nouveau et du côté applicatif, on utilise la nouvelle vue pour prendre en compte les nouvelles informations.
Peut-être que la nouvelle vue sera rédigée très différemment de la première mais comme on n'aura ajouté que quelques colonnes en plus sans changer le reste, il y aura très peu de choses à changer côté applicatif : seulement les nouveautés, ce qui serait de toute façon le cas avec ou sans ORM.

À titre d'exemple, je développe actuellement une application de gestion des personnes en formation chez nous (étudiants et profs stagiaires). J'ai pour le moments ces vues sur les candidats à venir chez nous :
- v_candidat ;
- v_candidat_bac (quel bac ont les candidats) ;
- v_candidat_diplomes (quels diplômes ont les candidats).

Pas impossible que j'en fasse d'autres. Et parmi les vues que j'ai déjà créées, certaines ont été modifiées sans toucher à tout le code applicatif qui les utilise.

[Sodium]

Non, une vue optimisée pour un panel de besoins définis.
Une vue modifiable côté SQL si la structure de la BDD change mais qui donnera les mêmes résultats à l'application qui n'aura pas à être modifiée, même si la vue est utilisée par plusieurs morceaux de programmes ou plusieurs applications.
J'ai besoin de cette vue avec d'autres informations ?
=> Je fais une nouvelle vue pour ce besoin nouveau et du côté applicatif, on utilise la nouvelle vue pour prendre en compte les nouvelles informations.
Peut-être que la nouvelle vue sera rédigée très différemment de la première mais comme on n'aura ajouté que quelques colonnes en plus sans changer le reste, il y aura très peu de choses à changer côté applicatif : seulement les nouveautés, ce qui serait de toute façon le cas avec ou sans ORM.

Tu réponds complètement à côté de la plaque. Je te demande comment faire pour pouvoir faire à peu près n'importe quoi avec les données au runtime sans toucher au code (que ce soit côté application ou côté db) et ta solution est de faire une vue pour chaque besoin... donc l'exact inverse.

C'est comme si un client me demandait un site Internet avec un CMS lui permettant d'éditer les contenus lui-même et que je lui répondais "voilà, faudra juste me passer me passer un coup de fil chaque fois que vous voulez faire une modif et je la ferrai pour vous, on va partir sur un forfait horaire minium de 70€... mais à part ça vous êtes totalement autonome hein !"

À titre d'exemple, je développe actuellement une application de gestion des personnes en formation chez nous (étudiants et profs stagiaires). J'ai pour le moments ces vues sur les candidats à venir chez nous :
- v_candidat ;
- v_candidat_bac (quel bac ont les candidats) ;
- v_candidat_diplomes (quels diplômes ont les candidats).

Mais quel bordel sérieusement...

Avec Doctrine je te fais des méthodes qui récupèrent l'information et je les appelle au besoin, avec des noms de fonctions clairs, sans préfixes qui vont inexorablement devenir de plus en plus nombreux et donc impossibles à retenir.

Ca donnerait donc quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$candidate = $candidateRepository
    ->getCandidates()
    ->withBac()
    ->withDiploma()
    ->fetch();

Voilà, si sur une page je n'ai besoin de rien je n'appelle rien, si j'ai besoin du bac je demande le bac, si j'ai besoin du diplome je demande le diplôme, si j'ai besoin les trier par la longueur de leur doigts de pied je rajoute une fonction sortByToesLength(string $direction = 'ASC'). Je ne me retrouve pas avec 500 vues qui font à peu près la même chose avec tellement de noms et de préfixes qu'au bout de six mois personne ne saura plus ce qui fait quoi ni où c'est utilisé, c'est clair, court et réutilisable.

Vous n'aidez vraiment pas à faire valoir votre point de vue hein

[StringBuilder]

SqlPro et Stringbuilder prétendent que générer des requêtes côté application ne devrait pas arriver

Ca c'est faux.

C'est toi depuis le début qui dit "pas d'ORM = pas de génération de SQL".

Pour ma part, et je pense aussi pouvoir parler au nom de SQLPro, un ORM ne devrait être utilisé que pour faire du CRUD sur des objets simples : tables unitaires ou vues. Et dans ce cas, on perd 90% de son intérêt, quelques lignes pour générer la requête dynamiquement suffisent alors.

Pour le moment, la réponse que j'ai eue c'est "suffit de faire une vue qui récupère toutes les valeurs possibles et imaginables", ce que je trouve moyennement convainquant

Car tu ne sais pas du tout comment fonctionne un SGBD ni les vues.
Tu peux faire une vue qui récupère la liste de toutes les commandes et le montant total de chacune d'entre elles (en faisant une jointure + aggrégation sur les lignes) et n'interroger que le numéro de commande et la date de commande à partir de cette vue. A ce moment, le SGBD ne va même pas chercher à faire une seule lecture sur les lignes.
Le plan d'exécution de la requête, y compris de la vue, est recompilé en fonction de la chaîne SQL exécutée.

PHPmyadmin est d'ailleurs un très bon exemple (de type d'application, pas le code, il est pourri). Comment on fait un PHPmyadmin sans générer de requêtes sql côté PHP ?

Sans utiliser d'ORM ?

[Sodium]

Ca c'est faux.
C'est toi depuis le début qui dit "pas d'ORM = pas de génération de SQL".

Je te cite : Renseigne-toi sur les bases de données épaisses avant de sortir des trucs pareils.

Le principe c'est justement de ne pas générer des requêtes SQL à la volée...

Je n'ai jamais dit qu'on ne pouvait pas générer du SQL sans ORM, j'ai dit qu'on ne peut pas le faire PROPREMENT sans au moins une classe string builder, et que donc autant utiliser un ORM déjà développé et testé.

Pour ma part, et je pense aussi pouvoir parler au nom de SQLPro, un ORM ne devrait être utilisé que pour faire du CRUD sur des objets simples

Ce qui correspond à peu près à 95% des besoins d'une application web standard

Car tu ne sais pas du tout comment fonctionne un SGBD ni les vues.
Tu peux faire une vue qui récupère la liste de toutes les commandes et le montant total de chacune d'entre elles (en faisant une jointure + aggrégation sur les lignes) et n'interroger que le numéro de commande et la date de commande à partir de cette vue. A ce moment, le SGBD ne va même pas chercher à faire une seule lecture sur les lignes.

Je n'ai pas dit que je n'avais pas compris, j'ai dit que l'idée est (pour être polie) mauvaise.

Ca serait bien d'arrêter les attaques sur les compétences à l'aveugle, j'ai probablement bien plus de compétences en SQL que toi en ORM.

Sans utiliser d'ORM ?

Dans ce cas précis je n'utiliserais probablement pas d'ORM justement, ça me paraît tordu d'en utiliser un pour interroger les tables système. notamment Par contre un query builder clairement oui.

[wallas00]

En terme de perf oui (sans doute), en terme de cout de devs non.


Logique recusive, mise en cache, gestion des exptions, utilisation de lib tierce, api tierce, gestion des logs, threads, il y a enormement de chose qui manquent ou sont ingerables pour un dev moyen cote bdd. Un dba va sans doute pouvoir le faire, mais a quel prix financier.


Des lors qu'une personne a une certaine expertise dans un domaine elle essaie de valoriser cette expertise, donc de defendre le domaine.


Le probleme reste entier cote code ou cote bdd si tu ajoute une propriete a ta classe il va falloir changer egalement pas mal de choses.


Il peut y avoir des gains de perf notable si tu denormalises certaines tables mais c'est une tache pas si evidente.



Il n'existe que je sache rien d'integre au cycle CI/DI donc migrations a la main. Le soucis est le meme pour les test unitaires.


Enfin dernier point, comment fait-tu pour versionner ta bdd, et travailler en equipe efficacement ?

Merci pour ta réponse.
Pour résumer: utiliser directement la puissance du SGBD est le chemin à suivre si on veut absolument de très bonnes performances avec une base relationnelle; cependant, les ingénieurs ayant les compétences requises coûtent chères.

Les SGBDR ont besoin selon moi d'une API solide, dont chaque langage pourra dériver un ORM. Un peu comme le JS(SQL) et le webassambly(?)

Pour ma part, je continuerais avec de l'orienté document et graphes. Pas besoin de versionning de DB, car pas de schéma dans la base de données. Les schémas correspondent à l’arborescence de classes de mes objets métiers et les opérations CRUD sur ces derniers sont supportées par une interface qui peut avoir une implémentation InMemory InDatabase InFile or whatever. La base de données ne me sert qu'à faire du stockage, et doit avoir un accès rapide en lecture/écriture.

[StringBuilder]

Ca donnerait donc quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$candidate = $candidateRepository
    ->getCandidates()
    ->withBac()
    ->withDiploma()
    ->fetch();

Voilà, si sur une page je n'ai besoin de rien je n'appelle rien, si j'ai besoin du bac je demande le bac, si j'ai besoin du diplome je demande le diplôme, si j'ai besoin les trier par la longueur de leur doigts de pied je rajoute une fonction sortByToesLength(string $direction = 'ASC'). Je ne me retrouve pas avec 500 vues qui font à peu près la même chose avec tellement de noms et de préfixes qu'au bout de six mois personne ne saura plus ce qui fait quoi ni où c'est utilisé, c'est clair, court et réutilisable.

Vous n'aidez vraiment pas à faire valoir votre point de vue hein

Ok, et chacune de tes méthodes, elles s'écrivent toutes seules ?
Si la longueur des pieds est déduite de la taille moyenne des chausses achetées sur les 12 derniers mois, ça va ressemble à quoi ?

T'as pas 500 vues, t'as 500 méthodes dans 500 classes, je suis pas certain que ce soit mieux.

Et le jour où ton chef te demande une autre application, sur une autre techno, qui doit manipuler la même base de données et y refaire les mêmes traitements et requêtes, 100% de ton code est à réécrire, sans aucune garantie que tu feras pareil… Et le jour où la base évolue, ouais, là tu vas commencer à pleurer car t'as toutes tes applications à modifier à cause d'une connerie de table de jointure qui s'est glissé entre deux tables utilisées dans 80% de tes traitements… je te plains réellement ce jour là.

[StringBuilder]

Je te cite : Renseigne-toi sur les bases de données épaisses avant de sortir des trucs pareils.

Le principe c'est justement de ne pas générer des requêtes SQL à la volée...

Changer la liste des colonnes et ajouter un filtre ou une clause order by, j'appelle pas ça générer des requêtes à la volée…
Et comme tu le dis si bien, au besoin on peut passer par un querybuilder (faudrait encore que ça en vaille la peine dans la mesure où on n'a même pas de jointures ou autres clauses de regroupement à gérer), en aucun cas un ORM.

[Sodium]

Ok, et chacune de tes méthodes, elles s'écrivent toutes seules ?

Non, mais elles font chacune 3 lignes en moyenne et sont chainables, donc réutilisables n'importe où dans l'application en fonction des besoins. Elles ont un nom très clair, donc parfaitement maintenables. Si quelqu'un repasse sur l'application dans trois ans, il comprendra immédiatement qu'est-ce qui fait quoi.

Je réalise après coup que tu ne comprends peut-être tout simplement pas le fonctionnement... chaque méthode n'est pas une requête indépendante, elle ne fait qu'ajouter des éléments à la requête finale qui sera exécutée.

Si la longueur des pieds est déduite de la taille moyenne des chausses achetées sur les 12 derniers mois, ça va ressemble à quoi ?

Probablement avec un average sur une sous-requête, je ne me prononcerai pas sur la manière idéale de faire ça. Dans tous les cas, ça ne change pas le principe. Dans le code, un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public function sortByAverageFeetLength(): self
{
    $this->query->addSelect('AVG(...) AS avgfeetlenght')
        ->addOrderBy('avgfeetlength');
 
    return $this;
}

T'as pas 500 vues, t'as 500 méthodes dans 500 classes, je suis pas certain que ce soit mieux.

Elles font combien de caractères tes vues ? Par quel nom sont-elles identifiées ? Si on change une colonne dans la table, on fait quoi des 500 vues précédentes ?

Et le jour où ton chef te demande une autre application, sur une autre techno, qui doit manipuler la même base de données et y refaire les mêmes traitements et requêtes, 100% de ton code est à réécrire, sans aucune garantie que tu feras pareil…

Pourquoi changer de techno pour commencer ? Quand une entreprise décide de se fixer sur un framework, c'est rarement pour en changer en fonction de la mode du jour. Par ailleurs, les ORM peuvent être utilisées dans différents frameworks, ou sans framework. Donc il suffit soit de recopier les entités et repositories (en modifiant éventuellement les noms de tables et de colonnes dans le paramétrage), soit, et c'est plus malin, de créer une librairie réutilisable dans tous les projets.

Dans tous les cas ça restera bien, bien plus simple que de changer de BDD lorsque toute la logique est dans cette dernière

[StringBuilder]

Logique recusive, mise en cache, gestion des exptions, utilisation de lib tierce, api tierce, gestion des logs, threads, il y a enormement de chose qui manquent ou sont ingerables pour un dev moyen cote bdd. Un dba va sans doute pouvoir le faire, mais a quel prix financier.

Logique récusrive
La norme SQL:1999 introduit les Common Table Expression (CTE) qui permettent parfaitement de faire de la récursivité. C'est un gâchis de le faire côté applicatif quelle que soit la méthode utilisé :
- Soit on effectue autant de requêtes qu'il y a de nœuds ou de niveau (selon le sens d'interrogation) là où en SQL il faut une seule requête
- Soit on charge toute les données en mémoire avant de travailler avec un arbre en mémoire, là où en SQL on peut s'affranchir de toute la logique du graph et ne charger que les données réellement requises
- Soit on stocke le chemin hiérarchique dans une colonne, ce qui permet partiellement de résoudre le problème des lectures, mais pénalise grandement toute mise à jour et perd de la place pour rien

mise en cache
Comme SQLPro aime à le rappeler, SQL Server dispose de plus d'une centaine de niveaux de cache… quel est l'intérêt d'en rajouter une couche ?
Comment gérer la cohérence des données si plusieurs applications modifient en même temps les données ? Apposer des locks ? Faire des plans sur la comète et planter au moment de l'écriture des données ? Restituer des informations fausses ?

Gestion des exceptions
Les SGBD-R dispose en interne de tous les mécanismes de transaction, verrous, contraintes et déclencheurs nécessaires pour valider et vérifier la cohérence des données qu'on insère.
Même pire, si votre programme valide les données et qu'au final le SGBD décide que vous violez une contrainte, alors c'est lui qui aura le dernier mot : vous ne pourrez jamais enregistrer une donnée invalide sans désactiver au préalable la contrainte. C'est d'ailleurs la première raison pour laquelle les développeurs utilisant des ORM n'utilisent que peu de contraintes… et que leurs programmes sont aussi peu fiables : comment ça j'ai pas assez de stock pour l'expédition que je viens de valider ? Je fais quoi maintenant ?


utilisation de lib tierce, api tierce
Tout dépend de ce que tu appelle lib et api tierces.
Il y a quelques années, je me suis amusé à écrire une DLL pour SQL Server permettant d'indexer le texte contenu dans des images (avec l'OCR tesseract) stockées dans une table, afin de pouvoir retrouver les images en fonction du texte qu'elles contenait.
La plupart des SGBD peuvent utiliser des extensions de la sorte. SQL Server c'est en .NET, et Oracle c'est en Java par exemple.

gestion des logs
Il existe de nombreuses libs permettant de gérer les logs côté serveur, dans une table.
C'est aussi une pratique plus que courante que de faire des logs depuis un trigger ou une procédure stockée directement en base.
Le plus gros avantage consiste dans la simplicité de requêtage par la suite...

threads
Toute requête SQL est implicitement multi-threadée en fonction de son plan d'exécution. Donc plus ta requête est complexe, plus il y a de chances qu'elle multi-threadée, alors que côté applicatif il va être très compliqué de scinder en thread des traitements imbriquées (par exemple, charger toutes les commandes, et compléter les données avec l'adresse du client dans un autre thread) et probablement contre performant (obligé d'attendre les premières lignes de commande avant de savoir les adresses de quels clients chercher)

Bref, au contraire, les DEV d'ancienne génération, mais de plus en plus, les DEV de nouvelle génération aussi, voient les SGBD comment "des fichiers stockés sur le disque, lent et compliqué".
C'est tout l'inverse : un SGBD est dédié à a gestion des données. Même si ton programme charge tout en cache, il est certain qu'il mettra plus de temps à s'y retrouver que s'il interrogeait le SGBD. C'est d'autant plus vrai dès que la base de données grossi un peu (compliqué de faire des boucles imbriquées sur des matrices de plusieurs millions de lignes). Bon, après, quand on a 3 tables avec 12 lignes, évidement que le SGBD ne sert à rien. Tout comme votre voiture lorsque vous voulez traverser la rue.

Quant au coût d'un développeur qui maîtrise le SQL, on ne parle pas d'un DBA… Juste d'un mec qui a passé quelques heures à se documenter et s'intéresser à la chose.

[Pyramidev]

Pour ma part, et je pense aussi pouvoir parler au nom de SQLPro, un ORM ne devrait être utilisé que pour faire du CRUD sur des objets simples : tables unitaires ou vues. Et dans ce cas, on perd 90% de son intérêt, quelques lignes pour générer la requête dynamiquement suffisent alors.

Du coup, il semble que nous soyons tous les deux d'accord sur le rôle que doit avoir un ORM, du moins par rapport à ce qu'il est capable de faire aujourd'hui. Même si mon précédent exemple avec les pays et les villes contenait une jointure faite par un ORM, j'aurais préféré que cette jointure soit derrière une vue SQL.

À quoi correspondent ces 90% perdus ?

Par contre, je ne crois pas que SQLPro soit d'accord sur l"utilisation de l'ORM, même pour faire des requêtes sur une table ou une vue. Dans ce fil, il a cité plusieurs fois son article Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ? qui conclut ceci à propos des ORM :

Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les geeks de s'affirmer, et pour les développeurs de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leur ignorance.

[mermich]

@StringBuilder

- Logique récursive
Je connais les CTE et c'est indigeste au possible.

- Mise en cache
Si tu laisses plusieures applications differentes taper directemnt contre la bdd et que cela ne te choque pas alors tant mieux pour toi.

- Gestion des exceptions
Oui la bdd peut faire cela et meme envoyer des emails (oui je l'ai deja fait). Ce n'est pas pour autant que c'est une bonne idee.

- Utilisation de lib tierce, api tierce
Donc comment a partir de SQLServer Cloud vas-tu faire cela, je suis hautement dubitatif.
Comment fais-tu ca avec postgres (une bdd qui ne supporte pas vraiment les dates)...
On peut aussi parler du cout de maintenance d'une lib java pour Oracle.

- Gestion des logs
Donc sur la bdd tu stockes les logs et les donnees, peut-on rester serieux au moins une minute ?

- threads
On va ommetre que cote code c'est une autre histoire, cote bdd un gros traitement qui dure plusieures heures est tres difficilement modifiable pour etre mis en plusisurs thread ( et controler manuellement les threads).


T'as oublie et de trouver des exemples pour :

• Le debugging
• l'integration continue
• les deploiements (par exemple comment faire un revert d'une base de donnees si un deploiement a foire )
• les tests
• Le travail en equipe
• La gestion de versions

Pour reprendre une conclusion :

Finalement les seuls arguments positifs en faveur ce ces outils (les base de donees) sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les geeks de s'affirmer, et pour les développeurs de rester dans le concept table sans jamais aller voir du côté de l'objet, les enfonçant ainsi encore un peu plus dans leur ignorance.

[Sodium]

Oui, c'est exactement ça. La seule justification du tout DB, c'est de nécessiter un db admin pour la moindre application. Ca crée des emplois

Sinon, le youtuber de la chaîne Primum non nocere expliquait qu'en médecine, on ne dit jamais jamais et jamais toujours. Ca me semble s'appliquer particulièrement bien au domaine du développement et certains ici devraient peut-être y réfléchir un peu.

[StringBuilder]

À quoi correspondent ces 90% perdus ?

A tout ce que les ORM "savent" faire d'autre.
A savoir justement, soit-disant des requêtes complexes, mais aussi et surtout la conception de la base de données depuis le programme (le fameux "code first").

Par contre, je ne crois pas que SQLPro soit d'accord sur l"utilisation de l'ORM, même pour faire des requêtes sur une table ou une vue. Dans ce fil, il a cité plusieurs fois son article Darwinisme et informatique : les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ? qui conclut ceci à propos des ORM :

Même si ça n'engage que moi et que Frédéric confirmera ou non, je pense que sa vision des ORM est proche de la mienne : tant qu'elle se cantone à du CRUD, il n'y a pas vraiment de contre indication.
En revanche, là où ça nous donne des boutons, c'est quand un développeur commence à coder tous les accès aux données en "pensant ORM" sans avoir la moindre idée des tables utilisées derrière, et en justifiant son choix en arguant que le modèle des données de la base est pourri et illisible, puisqu'il résulte généralement de cette volonté aveugle de n'utilise que l'ORM plutôt que d'avoir conceptualisé les données avant.

[Sodium]

Faudra vous rendre compte un jour qu'une bonne parties des applications web utilisent un ORM, sont performantes et surtout maintenables. Vous pouvez analyser ça comme vous voulez, critiquer, ça ne changera pas la réalité

Les ORM sont là parce qu'ils répondent à un besoin et ils le font très bien. Restez dans votre monde si vous voulez, mais arrêtez d'empoisonner l'air avec vos idées arriérées ne reposant sur rien de concret.

[vertex.3F]

Faudra vous rendre compte un jour qu'une bonne parties des applications web utilisent un ORM, sont performantes et surtout maintenables. Vous pouvez analyser ça comme vous voulez, critiquer, ça ne changera pas la réalité

Les ORM sont là parce qu'ils répondent à un besoin et ils le font très bien. Restez dans votre monde si vous voulez, mais arrêtez d'empoisonner l'air avec vos idées arriérées ne reposant sur rien de concret.

bonjour Sodium,

merci pour toutes tes contributions sincères qui font preuve à mes yeux d'une belle volonté de partage et de pédagogie (=l'esprit d'un forum d'entraide).

Mais ... "keep cool" ! Ne perds pas ton temps et ton énergie à lutter contre les moulins à vent, dans ce fil certains avancent des arguments qui sont d'une autre époque, certains ne comprennent pas autre chose que ce qu'ils connaissent déjà (par leur volonté ou leur capacité ?), d'autres sont taquins (trollers) ou de mauvaise foi, certains sont DBA et pas développeurs, d'autres sont des chefs de projets de l'ancien temps, d'autres n'y connaissent rien ou n'y comprennent rien, etc. C'est logique car - en caricaturant - on peut faire du SQL sans rien connaitre au développement informatique moderne des entreprises et du coup on peut donner son avis sur le SQL.

Perso en tant que développeur JEE la plupart du temps l'utilisation d'un ORM représente pour moi un gain c'est pourquoi je l'utilise volontiers car ça va dans le sens de la structuration du code (design patterns), la factorisation (gestion de la connexion, des exceptions, etc.), de la robustesse, etc.
En JEE les API JPA d'hibernate ou eclipselink beneficient de nombreux tests et correctifs depuis plusieurs années, ce qui représente un socle sûr; et JPA intègre "proprement" la possibilité d'écrire du SQL natif lorsque le besoin s'en fait sentir ( les concepteurs d'ORM ne sont pas idiots et inexpérimentés , au contraire ils écrivent un ORM parce qu'ils ont l'expérience de devoir réécrire chaque fois le même pattern d'acces au données, de gestion des transactions, de gestion des exceptions, etc. cela dans de nombreux langages https://en.wikipedia.org/wiki/List_o...pping_software )

à +

[blbird]

bonjour Sodium,

merci pour toutes tes contributions sincères qui font preuve à mes yeux d'une belle volonté de partage et de pédagogie (=l'esprit d'un forum d'entraide).

Mais ... "keep cool" ! Ne perds pas ton temps et ton énergie à lutter contre les moulins à vent, dans ce fil certains avancent des arguments qui sont d'une autre époque, certains ne comprennent pas autre chose que ce qu'ils connaissent déjà (par leur volonté ou leur capacité ?), d'autres sont taquins (trollers) ou de mauvaise foi, certains sont DBA et pas développeurs, d'autres sont des chefs de projets de l'ancien temps, d'autres n'y connaissent rien ou n'y comprennent rien, etc..

Oh oui, merci Sodium du partage de tes avis si doux, de tes connaissances si complètes, de ta capacité à ne jamais dire du mal des autres ou des technos que tu ne connais pas, de tes avis si pondérés et modérés, et de cette faculté à faire discuter sereinement tous les intervenants des topics où tu interviens. Et pleins de bisous au popotin surtout.

C'est logique car - en caricaturant - on peut faire du SQL sans rien connaitre au développement informatique moderne des entreprises et du coup on peut donner son avis sur le SQL

Encore heureux qu'on puisse donner son avis sur le SQL quand on le connait. L'inverse est beaucoup moins vrai.

Perso en tant que développeur JEE la plupart du temps l'utilisation d'un ORM représente pour moi un gain c'est pourquoi je l'utilise volontiers car ça va dans le sens de la structuration du code (design patterns), la factorisation (gestion de la connexion, des exceptions, etc.), de la robustesse, etc.
En JEE les API JPA d'hibernate ou eclipselink beneficient de nombreux tests et correctifs depuis plusieurs années, ce qui représente un socle sûr; et JPA intègre "proprement" la possibilité d'écrire du SQL natif lorsque le besoin s'en fait sentir ( les concepteurs d'ORM ne sont pas idiots et inexpérimentés , au contraire ils écrivent un ORM parce qu'ils ont l'expérience de devoir réécrire chaque fois le même pattern d'acces au données, de gestion des transactions, de gestion des exceptions, etc. cela dans de nombreux langages https://en.wikipedia.org/wiki/List_o...pping_software )

Beaucoup de etc. ici. Ce n'est pas parce qu'il y a des DP que c'est forcément mieux structuré. Ce n'est pas parce qu'une techno a des DP objets qu'elle est forcément mieux qu'une autre qui n'en a pas. Il n'y a pas forcément besoin d'un ORM pour gérer l'accès aux données, ni gérer les transactions, et encore moins gérer des exceptions.

Tout est une question de coûts et de gains. Aucun solution, avec ORM ou sans, n'est parfaite, loin de là. Contrairement à ce que votre "idole" raconte.