Absolument pas d'accord. Les ORM produisent essentiellement du code SQL-92 et des requêtes transactionnelles relativement basiques. Il y a moins de risques que l'optimiseur se plante, à part si, paradoxalement, il est trop riche. L'optimiseur d'Oracle est le cas typique. Il produit des plans allant du catastrophique à l'excellent là où le planner de PostgreSQL se situe plus souvent entre le bon et le très bon.
Je me suis rendu compte au fil du temps que les gadgets fournis par Oracle servent essentiellement à compenser les cas catastrophiques. Depuis 3 ans, je compare les plans d'exécutions produits avec Oracle et PostgreSQL, entre autres pour les requêtes nécessitant un SQL profile ou autre fonctionnalité exotique. Ma conclusion est que le planner de PostgreSQL se plante bien moins souvent par défaut que l'optimiseur d'Oracle, ce qui rend inutile les gadgets. Dans les rares cas où il se plante, il y a toujours moyen de le faire rentrer dans le droit chemin sans modifier le code SQL applicatif en jouant sur les statistiques, les paramètres de niveau session etc.
De manière générale, les outils et évolutions d'Oracle Database servent surtout à compenser les énormes problèmes générés par Oracle Database lui-même. Le meilleur exemple est la shared pool, la zone de partage des plans. Sur le papier c'est génial mais dans les faits ça consomme une quantité énorme de RAM qui n'est plus disponible pour mettre en cache les données. Cette zone est un poison et Oracle tente d'introduire des contrepoisons au fil des versions : bind peeking, adaptive cursor sharing…qui ne font que consommmer davantage de RAM et ajouter à la complexité.
Oracle pleure à ce sujet en disant qu'il faut développer en pensant à leur architecture. Cela signifie quoi ? Qu'Oracle admet qu'Oracle Database est un très mauvais choix lorsqu'on se "branle du SGBD". C'est LE SGBD le plus dépendant de ses DBA, ce qui le rend au départ peu éligible pour être une base de données dans le cloud. Larry Ellison & Co en ont d'ailleurs bien conscience avec la 18c présentée comme "autonome".
[^] # Re: N'importe quoi !
Posté par pgphil . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 10.
Absolument pas d'accord. Les ORM produisent essentiellement du code SQL-92 et des requêtes transactionnelles relativement basiques. Il y a moins de risques que l'optimiseur se plante, à part si, paradoxalement, il est trop riche. L'optimiseur d'Oracle est le cas typique. Il produit des plans allant du catastrophique à l'excellent là où le planner de PostgreSQL se situe plus souvent entre le bon et le très bon.
Je me suis rendu compte au fil du temps que les gadgets fournis par Oracle servent essentiellement à compenser les cas catastrophiques. Depuis 3 ans, je compare les plans d'exécutions produits avec Oracle et PostgreSQL, entre autres pour les requêtes nécessitant un SQL profile ou autre fonctionnalité exotique. Ma conclusion est que le planner de PostgreSQL se plante bien moins souvent par défaut que l'optimiseur d'Oracle, ce qui rend inutile les gadgets. Dans les rares cas où il se plante, il y a toujours moyen de le faire rentrer dans le droit chemin sans modifier le code SQL applicatif en jouant sur les statistiques, les paramètres de niveau session etc.
De manière générale, les outils et évolutions d'Oracle Database servent surtout à compenser les énormes problèmes générés par Oracle Database lui-même. Le meilleur exemple est la shared pool, la zone de partage des plans. Sur le papier c'est génial mais dans les faits ça consomme une quantité énorme de RAM qui n'est plus disponible pour mettre en cache les données. Cette zone est un poison et Oracle tente d'introduire des contrepoisons au fil des versions : bind peeking, adaptive cursor sharing…qui ne font que consommmer davantage de RAM et ajouter à la complexité.
Oracle pleure à ce sujet en disant qu'il faut développer en pensant à leur architecture. Cela signifie quoi ? Qu'Oracle admet qu'Oracle Database est un très mauvais choix lorsqu'on se "branle du SGBD". C'est LE SGBD le plus dépendant de ses DBA, ce qui le rend au départ peu éligible pour être une base de données dans le cloud. Larry Ellison & Co en ont d'ailleurs bien conscience avec la 18c présentée comme "autonome".