Pourquoi les fonctionnalités des bases de données sont-elles ignorées et réinventées au niveau intermédiaire ?

Question

Quelles sont les principales raisons ( à part "l'indépendance de la base de données" ) que la plupart des projets informatiques semblent aujourd'hui ignorer la richesse des fonctionnalités qui existent dans les moteurs de bases de données modernes tels qu'Oracle 11g et SQL Server 2008 ?

Ou, pour emprunter au Blog de la Déclaration d'Helsinki qui le dit de cette façon :

Au cours des vingt dernières années, nous avons constaté que les fonctionnalités disponibles dans les SGBD ont connu une croissance exponentielle. Ces fonctionnalités nous ont permis de construire des applications de base de données. C'est ce que nous avons tous commencé à faire dans les années 90, en plein essor.

Mais à l'aube du nouveau millénaire, quelque chose s'est produit. Et ce quelque chose a mystérieusement fait que le rôle du SGBD au sein d'un projet d'application de base de données a diminué jusqu'à devenir insignifiant. (...) Depuis le nouveau millénaire, nous poussons toute la logique applicative hors du SGBD vers des serveurs de niveau intermédiaire. La fonctionnalité des éléments implémentés en dehors du SGBD a explosé, et le SGBD riche en fonctionnalités n'est pratiquement plus utilisé que pour le stockage des lignes.

Nous parlons de choses comme

• Procédures stockées utilisées comme API de données (pour la sécurité et pour éviter un trafic réseau excessif)
• Vues matérialisées
• Au lieu de déclencher
• Requêtes hiérarchiques (connect by)
• Géographie (types de données spatiales)
• Analytique (lead, lag, rollup, cube, etc.)
• Base de données privée virtuelle (VPD)
• Audit au niveau de la base de données
• Requêtes flashback
• Génération XML et transformation XSL dans la base de données
• Appels HTTP à partir de la base de données
• Planificateur de tâches en arrière-plan

Pourquoi ces fonctionnalités ne sont-elles pas utilisées ? Pourquoi la plupart des développeurs Java, .NET et PHP s'en tiennent-ils à l'approche "SELECT * FROM mytable" ?

Answer 1

Parce que les procédures stockées :

• ajouter un autre langage de développement, ce qui augmente la complexité et le code potentiellement redondant (logique écrite dans les deux langages) ;
• ont généralement des outils, des capacités de surveillance et de débogage moins performants que PHP, C#, Java, Python, etc ;
• sont généralement moins performants que la plupart des langages de niveau intermédiaire ;
• n'ont un avantage que pour la transformation de gros volumes de données (où vous évitez les allers-retours avec le serveur), ce qui tend à ne représenter qu'un minimum de l'utilisation réelle.

Cela dit, il s'agit d'une méthodologie courante dans les applications C# ASP.NET.

Comme l'a dit Jeff Atwood, les procédures stockées sont le langage d'assemblage des bases de données et les gens n'ont pas tendance à coder en langage assembleur sauf si c'est nécessaire.

J'ai fréquemment utilisé des vues matérialisées et parfois utilisé CONNECT BY dans Oracle, mais je ne pense pas que ces deux méthodes existent dans MySQL.

Je n'ai pas tendance à utiliser XML/XSLT dans la base de données parce que, eh bien, cela signifie que j'utilise XML et XSLT.

En ce qui concerne les structures de données géographiques ou spatiales, la raison en est probablement qu'il est difficile de s'y retrouver. C'est un domaine assez spécialisé. J'ai lu le manuel MySQL sur les structures de données spatiales et je suis sûr que cela a du sens pour quelqu'un qui a une grande expérience des SIG, mais pour moi et mes besoins limités (qui tendent à être autour du marquage de la latitude/longitude d'un point), cela ne semble pas valoir la peine d'investir du temps pour le comprendre.

Un autre problème est que si vous allez au-delà de ANSI SQL (beaucoup), vous vous attachez à un fournisseur de base de données particulier et éventuellement à une version spécifique. C'est pourquoi les développeurs d'applications ont souvent tendance à traiter leurs bases de données selon le plus petit dénominateur commun, c'est-à-dire comme une décharge pour les données relationnelles.

Answer 2

Parce que les développeurs ne connaissent pas le SQL. Ils s'appuient sur les DDL et DML générés par des outils comme Hibernate et des constructions au niveau du langage comme les annotations JPA. Les développeurs ne se soucient pas de savoir si ces éléments sont terriblement inefficaces, car ils sont heureusement cachés par les niveaux de journal normaux et parce que les administrateurs de bases de données ne font pas partie des équipes de développement.

C'est pourquoi j'aime les outils iBATIS . Ils vous font écrire et comprendre SQL, y compris les fonctionnalités spécifiques aux SGBD.

Answer 3

Je pense que l'une des raisons est la peur de la fermeture des fournisseurs.

On ne le dit pas souvent, mais les avantages de l'utilisation de fonctionnalités spécifiques à un fournisseur doivent être mis en balance avec le coût. Principalement le coût de la réécriture des parties qui reposent sur des fonctionnalités spécifiques au fournisseur pour chaque base de données que vous souhaitez prendre en charge. Il y a également un coût de performance si vous implémentez quelque chose de manière générale alors que le fournisseur propose une meilleure solution.

J'évoquerai cet exemple : on pourrait trouver le "verrouillage" de SQL Server plus acceptable une fois que l'on a réalisé tout ce que les services d'analyse, les services de rapport, etc. peuvent faire pour votre application. Pour les principaux systèmes de base de données commerciaux, il ne faut pas tenir compte "seulement" du moteur de base de données SQL.

Answer 4

"Pourquoi les fonctionnalités des bases de données sont-elles ignorées".

Parce que beaucoup de soi-disant développeurs sont complètement ignorants de la gestion des données, et ce qui est pire, ils sont aussi complètement ignorants de leur ignorance. "Sans compétence et sans conscience", pour qui cela sonne bien.

Answer 5

Si votre logiciel fonctionne sur le matériel de votre client, toute modification de la base de données (nouvelles procédures stockées, vues mises à jour, etc.) nécessitera des droits d'administrateur de la base de données. C'est presque toujours un problème pour les clients. Le fait d'impliquer le groupe DB complique les mises à jour que vous devez effectuer. Il y a beaucoup de bonnes raisons présentées ici, mais c'est la seule dont j'ai besoin pour éviter de mettre du code dans la base de données comme la peste.