Pourquoi les fonctionnalités de base de données sont-elles ignorées et réinventées à la place dans le niveau intermédiaire?

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

Ou, pour emprunter le blog de la Déclaration d'Helsinki qui le présente ainsi:

Au cours des vingt dernières années, nous observons que les fonctionnalités (caractéristiques) qui nous sont disponibles dans le SGBD, ont augmenté de façon exponentielle. Ces fonctionnalités nous ont permis de créer 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 alors à l'aube du nouveau millénaire, quelque chose s'est produit. Et ce quelque chose a rendu mystérieusement insignifiant le rôle du SGBD dans un projet d'application de base de données. (...) A partir du nouveau millénaire, nous poussons toute la logique applicative 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 est à peine utilisé pour autre chose que le stockage en ligne.

Nous parlons de trucs 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
• Déclencheurs au lieu de
• Requêtes hiérarchiques (connexion par)
• Géographie (types de données spatiales)
• Analytics (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 de la base de données
• Planificateur de travaux 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"?

Parce que les procédures stockées:

• ajouter un autre langage de développement, augmentant la complexité et le code potentiellement redondant (logique écrite dans les deux langues);
• ont généralement de pires capacités d'outillage, de surveillance et de débogage que PHP, C #, Java, Python, etc.
• sont généralement moins capables que la plupart des langues de niveau intermédiaire;
• n'ont qu'un avantage avec la transformation de données à volume élevé (où vous évitez l'aller-retour du serveur), qui a tendance à n'être qu'un minimum d'utilisation réelle.

Cela étant dit, il s'agit d'une méthodologie courante sur 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 d'assemblage à moins qu'ils n'en aient besoin.

J'ai fréquemment utilisé des vues matérialisées et parfois utilisé CONNECT BY dans Oracle, dont je crois qu'aucune n'existe dans MySQL.

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

En ce qui concerne les structures de données géographiques ou spatiales, la raison est probablement qu'elles sont difficiles à «saisir». 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 avec une vaste expérience SIG, mais pour moi et mes besoins limités (qui ont tendance à être autour du marquage de la latitude / longitude d'un point) cela ne fait tout simplement pas. Cela ne vaut pas 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 êtes simplement lié quelque peu à un fournisseur de base de données particulier et éventuellement à une version spécifique. Pour cette raison, vous constaterez souvent que les développeurs d'applications auront tendance à traiter leurs bases de données au plus petit dénominateur commun, ce qui signifie les traiter comme un dépotoir pour les données relationnelles.

Parce que les développeurs ne connaissent pas SQL. Ils s'appuient sur DDL et DML générés par des outils tels que Hibernate et des constructions au niveau du langage telles que les annotations JPA. Les développeurs ne se soucient pas de savoir si ceux-ci sont horriblement inefficaces parce qu'ils sont heureusement cachés par les niveaux de journalisation normaux et parce que les administrateurs de base 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.

Je suppose que l'une des raisons est la peur du verrouillage des vendeurs.

Cela ne se dit pas souvent, mais les avantages de l'utilisation de fonctionnalités spécifiques aux fournisseurs doivent être comparés au coût. Principalement le coût de la réécriture des pièces 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 lorsque le fournisseur propose une meilleure solution.

Je vais évoquer cet exemple: on peut trouver que le "verrouillage" de SQL Server est plus acceptable une fois que l'on se rend compte de tout ce que Analysis Services, Reporting Services, etc. peut faire pour votre application. Pour les grands systèmes de bases de données commerciaux, ce n'est pas "seulement" le moteur de base de données SQL qui doit être pris en compte.

"Pourquoi les fonctionnalités de la base de données sont-elles ignorées".

Parce que beaucoup de soi-disant développeurs ignorent complètement la gestion des données, et ce qui est pire, ils ignorent complètement leur ignorance aussi. «Non qualifié et inconscient», pour qui cela sonne une cloche.

Si votre logiciel s'exécute 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 base de données. C'est presque toujours un problème pour les clients. L'implication du 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.

Je suppose que l'une des raisons est la peur du verrouillage des vendeurs. Ces fonctionnalités de SGBD ne sont pas standardisées - par exemple, les procédures stockées sont très spécifiques à la base de données, et si vous avez implémenté des éléments à l'aide de procédures stockées (au lieu, par exemple, de services Web exposés via un niveau intermédiaire), vous êtes à jamais coincé avec le SGBD choisi en premier. , (c'est-à-dire, sauf si vous êtes prêt à dépenser du temps / de l'argent pour le réimplémenter dans un autre SGBD si vous vouliez changer de SGBD).

MySQL.

Lorsque les applications Web ont explosé à la fin des années 1990 et au début des années 2000, MySQL était à la version 3.3 ou 4.0 et ne supportait rien au-dessus des simples SELECTs. Il était cependant gratuit et installé avec la plupart des distributions Linux. En conséquence, une génération de programmeurs n'a pas appris sur les bases de données et ne sait pas comment les utiliser.

Même maintenant que MySQL est à 5.1 et prend en charge la plupart des fonctionnalités d'un système commercial, les mêmes vieux blogs et articles grossiers sont utilisés comme modèles lorsqu'un nouveau projet LAMP est lancé, et MySQL est déployé avec des tables MyISAM et des fonctionnalités de l'ère 3.3. .

SQL échoue pour la même raison que par exemple Haskell. La métrique qui détermine le succès d'un langage n'est pas la pureté, ni la facilité d'interprétation par les ordinateurs, mais la difficulté à maintenir les programmes écrits dans celui-ci.

Les simples mortels échouent même avec le langage le plus simple. Peut-être qu'une personne sur dix a les compétences nécessaires pour utiliser un langage simple comme C #. Mais parmi ces 10%, seulement 1 personne sur 10 ou 1% de toutes les personnes peut utiliser efficacement des langages comme SQL ou Haskell.

Maintenant, SQL est incomplet en tant que langage, en ce sens qu'il y a très peu de choses que vous pouvez faire avec juste SQL. Vous aurez toujours besoin d'une autre langue. Quel rôle cela laisse-t-il à SQL? Les développeurs comprendront les avantages d'ACID par rapport au stockage de fichiers plats, mais en plus, les bases de données n'ont vraiment rien à leur offrir.

Un deuxième problème est que SQL n'est effectivement pas très compatible avec le contrôle de version source. SQL semble vraiment construit sur l'idée que vous faites les choses correctement du premier coup. Donc, ce n'est pas seulement mal adapté aux développeurs, c'est aussi un mauvais match pour le processus de développement.

Il est plus facile de réparer / redéployer le niveau intermédiaire que le SGBD.

Cela dépend probablement de votre architecture, mais c'est notre raison. Ajoutez à cela le fait que nous avons un DBA qui est plus occupé et (probablement) payé plus que nos développeurs. Tous les développeurs connaissent SQL et certains d'entre eux sont semi-versés dans le langage procédural. Si un problème de production vraiment épineux survient, il serait plus facile et plus rapide pour les développeurs de travailler sur le niveau intermédiaire que sur la base de données, que l'architecture soit meilleure dans un sens ou dans l'autre.

J'ai rencontré pas mal de gens qui ne savaient tout simplement pas que de telles fonctionnalités existaient - ils se sont fait les dents dans les premiers jours de mySQL, et ils n'ont jamais vraiment utilisé autre chose, et ils n'ont pas suivi le rythme. l'avancement des nouvelles tables de stockage dans mySQL, même. Ou ils ont appris les bases de données à l'école, et ils ne sont jamais retournés voir tout ce qu'ils ont manqué.

Ils apprennent le strict minimum SQL pour s'en sortir, et ne réalisent pas toutes les différentes extensions offertes par différents SGBDR.

Sur un projet, j'aimerais avoir des vues matérialisées ... mais j'utilise Postgres. J'adorerais utiliser des types de données spatiales pour un autre projet, mais je vais devoir faire un piratage ou modifier les bases de données pour faire face à l'insistance de mySQL selon laquelle elles ne sont pas nulles. J'ai même dû trouver comment désactiver la cohérence transactionnelle d'Oracle pour traiter des requêtes de longue durée sur un OLTP qui n'auraient pas posé de problème dans mySQL.

Je peux normalement coder autour des lacunes de la base de données pour un problème donné, mais une partie du problème réside dans la sélection du bon outil pour le travail - sur un projet en cours, nous avons gaspillé des mois-homme sur la réplication de données parce que nous sommes en utilisant Postgres, et ils ont opté pour Slony-1 avant de savoir réellement tout ce que nous répliquerions.

... Je considère cette question comme «pourquoi plus de gens n'utilisent-ils pas la fonctionnalité x dans la langue y » - s'ils ne sont pas experts en langue y, ils ne savent peut-être pas que la fonctionnalité x existe.

(et ne prenez pas cela comme un support pour obtenir la certification DBA ... J'ai connu des DBA Oracle qui ne pouvaient pas programmer leur sortie d'un sac humide; J'ai suivi tous les cours au cours des 8i jours, mais a refusé de passer les tests car je ne voulais pas être regroupé avec ce groupe)

Je pense que la principale raison qui éclipse tout le reste est que les systèmes de bases de données relationnelles deviennent considérablement plus importants lorsque plusieurs applications partagent les mêmes données. Le célèbre article de Codd est intitulé "Un modèle relationnel de données pour les grandes banques de données partagées " (c'est moi qui souligne).

Les gens ont tendance à penser que l'application qu'ils rédigent actuellement sera toujours contrôlée par leur équipe; et qu'il satisfera toujours tous les besoins des personnes intéressées par les données générées par l'application. Si un nouveau besoin survient, cela serait satisfait en ajoutant une nouvelle fonctionnalité à une application existante, et non en créant une nouvelle application.

Mais dans de nombreux cas (pas tous, bien sûr; chaque situation est différente), ce modèle de développement ne fonctionne pas très bien à long terme. Au fur et à mesure que les données générées par l'application s'accumulent et deviennent plus importantes pour l'entreprise, différentes personnes auront des idées intéressantes sur la façon d'utiliser les données. Lorsque cela se produit, si vous ne disposez pas d'un système de gestion de base de données relationnelle, vous êtes confronté à un grand défi.

Évolutivité. Plus vous donnez de travail au serveur de base de données, plus il devient un goulot d'étranglement. Il est plus évolutif d'avoir toute une batterie de serveurs d'applications à charge équilibrée traitant les données et d'utiliser simplement la base de données comme magasin de persistance.

J'ai été dans trop de situations où la politique d'entreprise ("nous n'avons pas autorisé l'accès au serveur SQL, donc installons un SGBD moins puissant comme Access pour traiter des millions de lignes et le joindre avec des millions de lignes dans une autre table, et permet d'automatiser cette importation .. ") ou même la politique technique qui peut arriver (" Je sais qu'Access peut gérer cette quantité de données et même si ce n'est pas le cas, nous pouvons diviser la MDB en plusieurs MDB et les référencer ..... ")

POUAH. La politique d'entreprise et la politique technique ou même l'ignorance m'ont empêché d'utiliser de nombreuses fonctionnalités.

Un autre exemple - je ne vois aucune raison de ne pas utiliser de procédures stockées dans une boutique 100% Microsoft où SQL Server est le SGBD de choix. Mais, parce que l'informaticien qui allait finalement posséder la solution était «léger» sur les SP, j'ai dû recourir à d'autres mesures. Je veux dire, il y a un exemple parfait de la raison pour laquelle certaines de ces «fonctionnalités» ont été ignorées par eux dans leur boutique.

Je connais un autre magasin qui utilise toujours DOS Foxpro 2 parce que leur seul informaticien a écrit le système existant de cette façon et c'est ainsi que toutes les nouveautés seront développées. Pourquoi? Ne pouvons-nous pas évoluer avec le temps? Beaucoup de gens du marketing là-bas ont plusieurs invites DOS ouvertes à la fois, avec des «jobs» Foxpro en cours d'exécution pour produire les rapports les plus laids que j'aie jamais vu. Mais ça marche - je vais leur donner ça. Cela fonctionne - ils ont 12 millions de lignes dans leur table principale et plus de 50 autres tables qu'ils `` rejoignent '' avec cette table principale (pas toutes les 50 à la fois évidemment) mais bon ... c'est bien après 1991! Ils ne veulent même pas discuter d'un élément de cette liste à puces que vous avez fournie dans votre question.

Des trucs comme ça, c'est pourquoi je suppose.

Je dirais que la principale raison est que la plupart des gens ne les connaissent pas. Une fois que quelqu'un a trouvé une solution à un problème, cela devient la solution par défaut pour des problèmes similaires. La table SELECT * FROM a fonctionné pour beaucoup de gens pendant longtemps, donc ils ne se soucient pas de regarder de nouvelles approches à d'anciens problèmes.

L'autre raison est que parfois l'écrire dans du code est beaucoup plus facile que d'utiliser une base de données. C'est la même idée que de rouler le vôtre ou d'acheter un composant standard. L'utilisation d'une fonctionnalité pré-écrite peut résoudre vos problèmes plusieurs fois, mais de temps en temps, vous devez faire quelque chose qui dépasse les capacités de ce que les composants pré-écrits peuvent effectuer.

Bonne question et bonne discussion.

Une autre façon de le dire est "pourquoi les bases de données d'objets n'ont-elles pas été capturées?" qui est le revers de la médaille. Les bases de données continuent d'être une abstraction ennuyeuse qui se fuit toujours dans toutes les applications, mais elles sont incompatibles avec la logique OO des applications modernes.

C'est en effet un étrange état de choses que nous masquions et dupliquions les fonctionnalités des bases de données dans ActiveRecord, Hibernate et autres middlewares. Mais c'est ce qui arrive aux paradigmes au point de rupture (le "discordance d'impédance objet-relationnelle"). Allons-nous un jour passer à des technologies de base de données similaires à nos applications OO (par exemple, des bases de données d'objets)?

La réponse est «pas pour longtemps» et en attendant, attendez-vous à ce que la base de données soit ignorée et écrasée et utilisée pour le stockage de lignes dans de nombreux cas, car le niveau intermédiaire se développe en fonctionnalités pour combler le fossé.

Une autre question est "pourquoi le ferais-je dans la base de données si le niveau intermédiaire peut le faire?" Le niveau intermédiaire est familier et gagne du terrain en vitesse et en fonctionnalité tout le temps. Encore une fois, nous utilisons le niveau intermédiaire pour éviter l'inadéquation OO-RDMS.

Pour avancer sur ce que Christian a dit, à propos de l'évolutivité.

Simplement, les RDBM sont davantage utilisés comme de purs magasins de données, tandis que la logique a migré vers les serveurs d'applications. Le niveau supplémentaire de l'AS donne aux développeurs plus de flexibilité que l'utilisation du SGBDR comme serveur d'applications.

Auparavant, à l'époque classique de Fat Apps et Client Server, la base de données et le serveur d'applications étaient fondamentalement la même chose. Vous aviez une logique d'application soit intégrée dans votre code client lourd, soit vous la repoussiez dans le SGBDR. Mais à l'époque, la principale forme de communication était SQL directement vers la base de données.

De nos jours, d'autres protocoles d'application sont plus courants (CORBA, DCOM, Remote EJB, et de plus en plus courants aujourd'hui les protocoles de style XML / JSON / HTTP-RPC sur HTTP). La plupart des bases de données ne répondent pas directement à ces protocoles, donc une couche Application est interceptée pour intercepter ces appels, et cette couche appelle la base de données.

Mais comme nous l'avons appris, nous bénéficions désormais d'une plus grande flexibilité en mettant de la logique dans cette couche. Choix plus large d'outils, plus de flexibilité sur la mise en cache, ou le basculement, ou même la technologie de base de données (RDMBS, OODBMS, magasins de documents comme CouchDB). Ce «nouveau» troisième niveau, malgré la complexité supplémentaire, ajoute plus de flexibilité et de puissance que la complexité qu'il introduit.

Lorsque le niveau de votre application est un placage très fin au-dessus des procédures stockées, il est légitime de se demander pourquoi il est même là.

Tirer parti de la base de données et de toutes ses fonctionnalités est une stratégie d'application valable, même aujourd'hui. SQL Server, Oracle, etc. sont des logiciels terriblement puissants.

Même dans ce cas, cependant, le troisième niveau est extrêmement utile pour ajouter de la flexibilité à un système moderne.

Pour moi, la raison n'est pas seulement que mes applications sont indépendantes de la base de données, mais une base de données préforme au mieux les fonctions CRUD de base. Oui, les bases de données sont hautement optimisées et pourraient être en mesure de faire un appel HTTP, mais pourquoi le feriez-vous? Un service Web / application Web est optimisé pour les appels HTTP, pas une base de données. Tout comme une application n'est pas conçue pour se connecter directement à un fichier de données et récupérer les données. Cela peut-il être fait? Oui mais pourquoi? Ce n'est pas ce que votre application EXCELLENT.

Je pense personnellement que tout ce que vous avez mentionné, en dehors des procédures stockées, appartient à l'application. Si vous savez que votre architecture est X, alors profitez des fonctionnalités de X, transférez le chargement au serveur de base de données le cas échéant, etc. essayer de créer la sécurité de l'emploi en vous assurant que vous devrez peut-être refactoriser l'application :). Je pense qu'un peu de paresse, combiné avec confort, pourrait avoir quelque chose à voir avec cela. Je sais que je préfère le faire en C # que SQL si je le peux. . . mes compétences en C # sont tout simplement meilleures.

Tout d'abord: tout développeur utilisant un ORM est naïf s'il pense que l'utilisation d'un ORM évite d'avoir à avoir des compétences SQL. La plupart des ORM qui génèrent du SQL varient le SQL émis en fonction de la manière dont les requêtes d'objet sont construites. Le développeur devra analyser le SQL pour voir s'il doit modifier l'une des requêtes d'objet.

Réponse courte: beaucoup de ces fonctionnalités ne sont pas pratiques pour le développement OO. Je sais que les DBA n'aiment pas entendre ça, mais c'est la vérité. Ces fonctionnalités sont bonnes pour les cas extrêmes et la plupart des bons ORM tels que N / Hibernate vous permettent de fournir du SQL pour ces cas extrêmes.

Lorsqu'il s'agit d'être principalement délégué à CRUD:

Réponse longue: je pense que le monde du SGBDR traverse des moments difficiles de maturité et trouve sa place dans le monde. Vérité: la POO est plus ancienne que le SGBDR. La POO sort juste de ses douleurs de croissance et de maturation. Je pense que SQL en tant que langage est très mature, mais l'idée de ce qu'un SGBDR doit gérer est en train de se régler. Le SGBDR était le détenteur de la logique métier de la plupart des applications Web jusqu'à l'arrivée de Java et C #. Je pense que nous commençons à peine à ressentir cette correction maintenant.

Cela étant dit, je ne pense pas qu'un concepteur ORM vous dira que la qualité des instructions SQL fournies au SGBDR n'a pas d'importance.

En ce qui concerne les non-CRUD, je n'ai pas de réponse ici. La plupart des magasins que je connais utilisent encore la base de données pour ETL / etc ...

Il n'y a pas assez de développeurs connaissant toutes ces fonctionnalités à un niveau qui ferait vraiment la différence pour un programmeur de niveau intermédiaire normal, lorsqu'il s'agit d'implémenter la même logique dans la base de données ou le niveau intermédiaire. Peut-être que les célibataires qui ont vraiment une connaissance approfondie de ces fonctionnalités sont les DBA. Et ceux-ci se concentrent sur d'autres problèmes que le développement. Il y a plus de développeurs «normaux» que de DBA. Il serait donc très difficile et coûteux de trouver les bonnes personnes pour votre équipe.

Un autre point est que vous ne collecterez normalement que des connaissances approfondies sur un système de base de données, et non sur tous. Vous pouvez donc avoir des experts SQL Server ou des experts Oracle, mais pas les deux. Cela conduit (dans une certaine mesure) à des domaines d'application étroits où une forte spécialisation compte. Ensuite, le marché de ces applications n'est pas si grand, même s'il existe.

Je pense que la raison est une combinaison de verrouillage du fournisseur et de manque de connaissances de la part de la plupart des utilisateurs de RDBM. SQL est un langage de programmation, et il est beaucoup plus difficile de maîtriser à la fois le langage à partir duquel vous appelez SQL et SQL que de maîtriser l'un ou l'autre, d'autant plus que SQL est un langage particulièrement unique.

La solution, je pense, est d'abstraire la fonctionnalité de votre base de données dans une classe utilitaire et de donner la propriété de la classe à quelques utilisateurs qui savent ce qu'ils font avec SQL. Cela minimise le risque de verrouillage du fournisseur (si vous changez de fournisseur, la seule chose qui est réécrite est la classe). Cela donne également aux développeurs qui ne sont pas des experts en SQL une interface abstraite afin qu'ils n'aient pas à traiter directement la base de données.

Une préoccupation que j'ai constatée lors de l'exploitation de la fonctionnalité de base de données accrue est la mise à l'échelle. Il semble être beaucoup plus difficile de faire évoluer la charge de votre base de données par rapport à la charge du serveur Web / d'applications.

Vos options sont limitées, évolutives avec un matériel plus gros et plus rapide (avec parfois des coûts de licence beaucoup plus élevés), ou compliquées, évolutivité avec des copies en lecture seule, etc.

S'il y a des problèmes de performances, je veux qu'ils soient au niveau de l'application du serveur Web. Au moins l'une de mes options consiste à ajouter un autre serveur Web et à répartir la charge.

Je ne discute pas contre le code au niveau de la base de données pour minimiser la quantité de trafic réseau (enregistrements) envoyé entre le serveur Web et le serveur de base de données. Je discute contre d'autres fonctionnalités, par exemple. traitement étendu de la logique métier au niveau de la base de données.

Quelques articles notent qu'il est moins coûteux de mettre à l'échelle au niveau de la couche application qu'au niveau de la couche db.

Une autre considération concerne les applications composites qui accèdent à plusieurs magasins de données. Il est beaucoup plus facile d'écrire et de gérer un langage de requête indépendant de la plate-forme dans le niveau application que des requêtes distinctes spécifiques à la plate-forme dans la couche db.

Parce que l'écriture de logiciels orientés objet, dans le langage hôte, avec des objets natifs du langage hôte, bat l'écriture de logiciels procéduraux.

J'ai toujours travaillé sur des systèmes vendus à de nombreux clients et fonctionnant sur le matériel du client. Cela mène à:

• Vous ne savez pas quelle version du logiciel de base de données le client exécutera.
• Les clients peuvent ne pas vouloir mettre à jour le logiciel de base de données quand vous le souhaitez en raison des coûts de licence ou de la politique informatique.
• Même les fonctionnalités de base comme les vues matérialisées ne sont que dans certaines «éditions» du logiciel de base de données, les plus petits clients ne sont souvent pas disposés à payer pour l'édition haut de gamme de la base de données.
• Tôt ou tard, l'un de vos commerciaux acceptera que votre logiciel soit utilisé avec le SGBDR d'un autre fournisseur.
• Choisir entre écrire la logique une fois dans le niveau intermédiaire ou au moins PL-SQL et TSQL dans la base de données est un choix facile!
• Toute modification de la base de données (nouvelles procédures stockées, vues mises à jour, etc.) nécessitera des droits d'administrateur de base de données; cela peut être beaucoup plus difficile sur le site de certains clients que de simplement mettre à jour votre logiciel.
• Ecrire un script pour mettre à jour la base de données est toujours plus difficile que d'installer une nouvelle version des DLL de l'application. (La plupart des systèmes de construction de nos jours produisent des fichiers MSI dans le cadre de chaque construction)
• Il est plus difficile de tester un code dans une base de données que dans un niveau intermédiaire.
• Il est plus difficile de déboguer les processus stockés que C #.
• Ce n'est pas parce qu'il fonctionne sur votre base de données qu'il fonctionnera sur la base de données du client que le SGBDR a trop de commutateurs qui modifient son fonctionnement - les clients ont toujours tendance à les configurer de différentes manières.

Compte tenu de tout ce qui précède, le gain lié à l'utilisation d'une fonctionnalité de base de données doit être important avant de valoir la peine à long terme.