Vous utilisez un ORM ou un SQL simple? [fermé]

Pour certaines des applications que j'ai développées (puis j'ai oublié), j'ai écrit du SQL simple, principalement pour MySQL. Bien que j'aie utilisé des ORM en python comme SQLAlchemy , je n'y suis pas resté longtemps. Habituellement, c'était la documentation ou la complexité (de mon point de vue) qui me retenait.

Je le vois comme ceci: utilisez un ORM pour la portabilité, du SQL simple si cela ne va utiliser qu'un seul type de base de données. Je suis vraiment à la recherche de conseils pour savoir quand utiliser un ORM ou SQL lors du développement d'une application qui a besoin d'un support de base de données.

En y réfléchissant, il serait bien préférable d'utiliser simplement un wrapper léger pour gérer les incohérences de la base de données par rapport à l'utilisation d'un ORM.

Les ORM ont de belles fonctionnalités. Ils peuvent gérer une grande partie du travail consistant à copier des colonnes de base de données dans des champs d'objet. Ils gèrent généralement la conversion des types de date et d'heure de la langue vers le type de base de données approprié. Ils gèrent généralement les relations un-à-plusieurs de manière assez élégante également en instanciant des objets imbriqués. J'ai trouvé que si vous concevez votre base de données en gardant à l'esprit les forces et les faiblesses de l'ORM, cela économise beaucoup de travail pour obtenir des données dans et hors de la base de données. (Vous voudrez savoir comment il gère le polymorphisme et les relations plusieurs-à-plusieurs si vous avez besoin de les cartographier. Ce sont ces deux domaines qui fournissent la plupart du «décalage d'impédance» qui fait d'ORM le «Vietnam de l'informatique». .)

Pour les applications qui sont transactionnelles, c'est-à-dire que vous faites une demande, obtenez des objets, parcourez-les pour obtenir des données et les rendre sur une page Web, la taxe sur les performances est faible, et dans de nombreux cas ORM peut être plus rapide car il mettra en cache les objets c'est vu auparavant, qui autrement aurait interrogé la base de données plusieurs fois.

Pour les applications qui génèrent des rapports volumineux ou qui traitent un grand nombre de lignes de base de données par demande, la taxe ORM est beaucoup plus lourde et la mise en cache qu'elles font se transforme en une lourde charge de stockage de mémoire inutile. Dans ce cas, un mappage SQL simple (LinQ ou iBatis) ou des requêtes SQL codées à la main dans un DAL léger est la solution.

J'ai trouvé que pour toute application à grande échelle, vous vous retrouverez à utiliser les deux approches. (ORM pour CRUD simple et SQL / DAL léger pour les rapports).

Parlant comme quelqu'un qui a passé pas mal de temps à travailler avec JPA (Java Persistence API, essentiellement l'API ORM normalisée pour Java / J2EE / EJB), qui comprend Hibernate, EclipseLink, Toplink, OpenJPA et d'autres, je vais partager certaines de mes observations.

1. Les ORM ne sont pas rapides. Ils peuvent être adéquats et la plupart du temps adéquats, c'est bien, mais dans un environnement à faible latence et à volume élevé, ce n'est pas le cas;
2. Dans les langages de programmation à usage général comme Java et C #, vous avez besoin de beaucoup de magie pour les faire fonctionner (par exemple, tissage de temps de chargement en Java, instrumentation, etc.);
3. Lorsque vous utilisez un ORM, plutôt que de vous éloigner de SQL (ce qui semble être l'intention), vous serez étonné du temps que vous passerez à peaufiner XML et / ou des annotations / attributs pour que votre ORM génère du SQL performant;
4. Pour les requêtes complexes, il n'y a vraiment aucun substitut. Comme dans JPA, il y a des requêtes qui ne sont tout simplement pas possibles qui sont en SQL brut et quand vous devez utiliser du SQL brut en JPA ce n'est pas joli (C # /. Net a au moins des types dynamiques - var - ce qui est beaucoup plus agréable qu’un tableau Object);
5. Il y a énormément de "pièges" lors de l'utilisation des ORM. Cela inclut un comportement inattendu ou inattendu, le fait que vous devez intégrer la capacité d'effectuer des mises à jour SQL dans votre base de données (en utilisant refresh () dans JPA ou des méthodes similaires car JPA par défaut met tout en cache pour ne pas intercepter une base de données directe mise à jour - l'exécution de mises à jour SQL directes est une activité courante de support à la production);
6. Le décalage objet-relationnel va toujours causer des problèmes. Avec un tel problème, il existe un compromis entre la complexité et l'exhaustivité de l'abstraction. Parfois, je sentais que JPA allait trop loin et frappait une véritable loi de rendements décroissants où la complexité n'était pas justifiée par l'abstraction.

Il y a un autre problème qui nécessite un peu plus d'explications.

Le modèle traditionnel pour une application Web est d'avoir une couche de persistance et une couche de présentation (éventuellement avec un service ou d'autres couches entre les deux mais ce sont les deux importantes pour cette discussion). Les ORM forcent une vue rigide de votre couche de persistance jusqu'à la couche de présentation (c'est-à-dire vos entités).

L'une des critiques des méthodes SQL plus brutes est que vous vous retrouvez avec tous ces VO (objets de valeur) ou DTO (objets de transfert de données) qui sont utilisés par une seule requête. Ceci est présenté comme un avantage des ORM parce que vous vous en débarrassez.

Le problème est que ces problèmes ne disparaissent pas avec les ORM, ils se déplacent simplement vers la couche de présentation. Au lieu de créer des VO / DTO pour les requêtes, vous créez des objets de présentation personnalisés, généralement un pour chaque vue. Comment est-ce mieux? À mon humble avis, ce n'est pas le cas.

J'ai écrit à ce sujet dans ORM ou SQL: en sommes-nous encore là? .

Ma technologie de persistance de choix (en Java) de nos jours est ibatis. C'est un wrapper assez mince autour de SQL qui fait 90% + de ce que JPA peut faire (il peut même faire du chargement paresseux des relations bien que ce ne soit pas bien documenté) mais avec beaucoup moins de frais généraux (en termes de complexité et de code réel).

Cela est apparu l'année dernière dans une application GWT que j'écrivais. Beaucoup de traduction d'EclipseLink vers des objets de présentation dans l'implémentation du service. Si nous utilisions ibatis, il aurait été beaucoup plus simple de créer les objets appropriés avec ibatis, puis de les passer tout le long de la pile. Certains puristes pourraient soutenir que c'est Bad ™. Peut-être que oui (en théorie) mais je vous dis quoi: cela aurait conduit à du code plus simple, une pile plus simple et plus de productivité.

Je dis SQL simple pour R eads, ORM pour CUD .

Les performances me préoccupent toujours, en particulier dans les applications Web, mais aussi la maintenabilité et la lisibilité du code. Pour résoudre ces problèmes, j'ai écrit SqlBuilder .

ORM n'est pas seulement la portabilité (ce qui est un peu difficile à réaliser même avec des ORM, d'ailleurs). Ce qu'il vous donne est essentiellement une couche d'abstraction sur un magasin persistant, lorsqu'un outil ORM vous libère de l'écriture de requêtes SQL standard (sélection par PK ou par prédicats, insertions, mises à jour et suppressions) et vous permet de vous concentrer sur le domaine problématique.

Toute conception respectable nécessitera une certaine abstraction pour la base de données, juste pour gérer le décalage d'impédance. Mais la première étape la plus simple (et adéquate pour la plupart des cas) que j'attendrais serait un DAL, pas un ORM lourd. Vos seules options ne sont pas celles situées aux extrémités du spectre.

EDIT en réponse à un commentaire me demandant de décrire comment je distingue DAL de ORM:

Un DAL est ce que vous écrivez vous-même, peut-être à partir d'une classe qui encapsule simplement une table et mappe ses champs aux propriétés. Un ORM est du code que vous n'écrivez pas ou des mécanismes d'abstraction déduits d'autres propriétés de votre schéma dbms, principalement des PK et des FK. (C'est là que vous découvrez si les abstractions automatiques commencent à fuir ou non. Je préfère les informer intentionnellement, mais cela peut être ma préférence personnelle).

Chaque outil a sa raison d'être et sa vision. J'ai créé http://www.jooq.org/ exactement pour répondre à vos besoins, mais iBatis est probablement aussi une bonne solution pour vous.

jOOQ a des fonctionnalités ORM de base, mais il se concentre principalement sur les choses dont je suppose que la plupart des développeurs ont le plus besoin, lorsqu'ils essaient de trouver le meilleur ORM pour leurs besoins:

• génération de code
• liaison variable (c'est un problème dans JDBC)
• Abstraction de syntaxe SQL (pour éviter les erreurs de syntaxe)

Mais souvent, ils vont trop loin et fournissent tellement d'abstraction que vous ne penseriez pas qu'ils fonctionnent contre un SGBDR. D'un autre côté, vous avez choisi un SGBDR précisément parce que

• c'est une source de données robuste
• SQL peut faire beaucoup de choses bonnes et performantes (sélections imbriquées, unions, jointures complexes, etc.). Souvent, les ORM ne peuvent pas faire ces choses.
• vous pouvez gérer vous-même les transactions et les sessions
• vous avez des procédures UDT et stockées

jOOQ aborde exactement ces points. Il fonctionnera aussi bien que JDBC, mais sans douleur.

Le dilemme d'utiliser ou non un framework est assez courant dans les scénarios de développement de logiciels modernes.

Ce qui est important à comprendre, c'est que chaque cadre ou approche a ses avantages et ses inconvénients - par exemple, selon notre expérience, nous avons constaté que l'ORM est utile lors du traitement des transactions, c'est-à-dire des opérations d'insertion / mise à jour / suppression - mais lorsqu'il s'agit de récupérer des données avec des résultats, il devient important d'évaluer les performances et l'efficacité de l'outil ORM.

Il est également important de comprendre qu'il n'est pas obligatoire de sélectionner un cadre ou une approche et de tout mettre en œuvre. Ce que nous entendons par là, c'est que nous pouvons avoir un mélange d'ORM et de langage de requête natif. De nombreux frameworks ORM donnent des points d'extension au plugin en SQL natif. Nous devons essayer de ne pas trop utiliser un cadre ou une approche. Nous pouvons combiner certains cadres ou approches et proposer une solution appropriée.

Vous pouvez utiliser ORM en ce qui concerne l'insertion, la mise à jour, la suppression, le contrôle de version avec un niveau élevé de concurrence et vous pouvez utiliser Native SQL pour la génération de rapports et la liste longue

La clé qui a vraiment fait voler mon utilisation ORM était la génération de code. Je suis d'accord que la route ORM n'est pas la plus rapide, en termes de performances de code. Mais lorsque vous avez une équipe moyenne à grande, la base de données modifie rapidement la capacité de régénérer les classes et les mappages à partir de la base de données dans le cadre du processus de génération est quelque chose de brillant à voir, surtout lorsque vous utilisez CI. Donc, votre code n'est peut-être pas le plus rapide, mais votre codage sera - je sais que je prendrais dans la plupart des projets.

Ma recommandation est de développer à l'aide d'un ORM alors que le schéma est encore fluide, d'utiliser le profilage pour trouver des goulots d'étranglement, puis de régler les zones qui en ont besoin en utilisant SQL brut.

Une autre pensée, la mise en cache intégrée à Hibernate peut souvent améliorer considérablement les performances si elle est utilisée de la bonne manière. Plus besoin de revenir à la base de données pour lire les données de référence.

Il n'y a pas de solution «un seul outil pour tous», et cela est également vrai pour la question «dois-je utiliser un ou / m ou non? '.

Je dirais: si vous devez écrire une application / un outil très axé sur les données, sans beaucoup d'autre logique, alors j'utiliserais du SQL simple, car SQL est le langage spécifique au domaine pour ce type d'applications.

D'un autre côté, si je devais écrire une application d'entreprise / entreprise qui contient beaucoup de logique de «domaine», j'écrirais alors un modèle de classe riche qui pourrait exprimer ce domaine en code. Dans ce cas, un mappeur OR / M peut être très utile pour le faire avec succès, car il vous enlève beaucoup de code de plomberie.

L'une des applications que j'ai développées était un bot IRC écrit en python. Les modules qu'il utilise s'exécutent dans des threads séparés, mais je n'ai pas trouvé de moyen de gérer le threading lors de l'utilisation de sqlite. Cependant, cela pourrait être mieux pour une question distincte.

J'aurais vraiment dû reformuler le titre et la vraie question. Je n'ai jamais utilisé de DAL auparavant, dans aucune langue.

Utilisez un ORM qui fonctionne comme SQL, mais qui fournit des vérifications à la compilation et une sécurité de type. Comme mon préféré: Data Knowledge Objects (divulgation: je l'ai écrit)

Par exemple:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

Streaming complet. Facile à configurer (pas de mappage à définir - lit vos schémas existants). Prend en charge les jointures, les transactions, les requêtes internes, l'agrégation, etc. Pratiquement tout ce que vous pouvez faire en SQL. Et a été prouvé à partir d'ensembles de données géants (séries temporelles financières) jusqu'à trivial (Android).

Je sais que cette question est très ancienne, mais je pensais que je posterais une réponse au cas où quelqu'un la rencontrerait comme moi. Les ORM ont parcouru un long chemin. Certains d'entre eux vous offrent en fait le meilleur des deux mondes: rendre le développement plus productif et maintenir les performances.

Jetez un œil aux données SQL ( http://sqldata.codeplex.com ). C'est un ORM très léger pour c # qui couvre toutes les bases.

Pour info, je suis l'auteur de SQL Data.

Je voudrais ajouter ma voix au chœur de réponses qui disent "Il y a un juste milieu!".

Pour un programmeur d'applications, SQL est un mélange de choses que vous voudrez peut-être contrôler et de choses que vous ne voudrez certainement pas être gêné de contrôler.

Ce que j'ai toujours voulu, c'est une couche (appelez-la DAL, ORM ou micro-ORM, ça ne me dérange pas) qui prendra en charge les décisions complètement prévisibles (comment épeler les mots clés SQL, où vont les parenthèses, quand d'inventer des alias de colonnes, quelles colonnes créer pour une classe qui contient deux flottants et un int ...), tout en me laissant en charge des aspects de niveau supérieur du SQL, c'est-à-dire comment organiser les JOIN, les calculs côté serveur, DISTINCT, GROUP BY, sous-requêtes scalaires, etc.

J'ai donc écrit quelque chose qui fait ceci: http://quince-lib.com/

C'est pour C ++: je ne sais pas si c'est le langage que vous utilisez, mais il pourrait tout de même être intéressant de voir ce que pourrait être un "terrain d'entente".