Essayer de choisir la bibliothèque d'API SQL

Question

Je commence tout juste à apprendre comment écrire un logiciel qui accède à un serveur SQL. Il semble que chaque implémentation serveur (Postgres, MySQL, etc.) propose des bibliothèques API pour différentes langues (mon code est en C et C++, même si les solutions pour Java et Python m'intéressent aussi). Cependant, je me méfie un peu de la dépendance à l'égard de ces bibliothèques, car je préfère une solution indépendante du fournisseur. Autant que je sache, l'API ODBC de Microsoft était destinée à résoudre de tels problèmes pour C/C++ (et JDBC pour Java); UnixODBC semble être une implémentation populaire. Ai-je raison même jusqu'ici?

En outre, ces bibliothèques fournissent-elles une interface orientée objet? Ce serait bien de ne pas simplement intégrer des requêtes SQL dans un autre langage plus riche en fonctionnalités; J'aimerais avoir un emballage qui imite le style du reste de la langue, aussi.

Y a-t-il donc une solution préférée dans ce sens? Est-ce que je demande quelque chose de bizarre?

Answer 1

En effet, ODBC/JDBC sont des bibliothèques qui aident à rendre l'interface d'appel standard entre les fournisseurs, mais vous avez raison de dire que chaque SGBDR respectif a son propre langage SQL. ODBC/JDBC ne permet pas d'abstraire la syntaxe SQL. Une solution pour déplacer le code SQL littéral hors de votre code d'application consiste à implémenter des requêtes dans les procédures stockées qui résident dans chaque back-end de base de données, puis à utiliser ODBC/JDBC pour appeler les procédures stockées. Vous pouvez définir des procédures stockées avec des noms similaires et une interface d'appel pour chaque type de SGBDR que vous utilisez. Mais sachez que le langage de procédure stockée est également variable d'un fournisseur à l'autre.

Une autre solution consiste à utiliser une technologie de «mapping relationnel objet» telle que Hibernate for Java ou NHibernate for .NET. Ces technologies peuvent le rendre plus «orienté objet» pour travailler avec des bases de données, et vous libérer de l'écriture littérale SQL dans de nombreux cas. Mais la plupart des outils ORM ont tendance à se concentrer sur des requêtes très simples. Si votre requête est complexe (en utilisant un GROUP BY ou un JOIN par exemple), l'utilisation de l'outil ORM est plus difficile que l'utilisation de SQL littéral.

Voir aussi « Good ORM for C++ solutions? »

Si SQL vous dérange tant que ça, vous allez probablement pas être heureux en utilisant un SGBDR du tout. Certains programmeurs ne voient pas la valeur des règles de normalisation, par exemple.Si cela est vrai pour vous, vous voudrez peut-être se pencher sur les nouvelles technologies pour les magasins de données non relationnelles, y compris:

• BerkeleyDB
• Project Voldemort
• CouchDB

Answer 2

ODBC/JDBC tentent de faire abstraction de l'interface de base de données pour fournir un modèle de programmation cohérent. Gardez à l'esprit que, en utilisant une telle interface avec le plus petit dénominateur commun, vous ne pouvez pas tirer parti des fonctionnalités spécifiques non standard qu'un DB donné peut offrir. Pour obtenir une interface orientée objet pour votre modèle de données, recherchez des solutions ORM (Object Relational Mapping) telles que Hibernate. Les solutions ORM mappent vos objets à leur représentation dans une base de données relationnelle, ce qui simplifie généralement la persistance des données d'une perspective de programmation d'applications.

Answer 3

Aussi près que Je peux dire que l'API ODBC de Microsoft était destinée à résoudre de tels problèmes pour C/C++ (et JDBC pour Java); UnixODBC semble être une implémentation populaire. Ai-je raison même jusqu'ici?

Oui. L'équivalent de ODBC ou JDBC pour Python est appelé DB-API. L'équivalent de Perl s'appelle DBI.

En outre, de telles bibliothèques fournissent-elles une interface orientée objet? Ce serait bien de ne pas simplement intégrer des requêtes SQL dans un autre langage plus riche en fonctionnalités; J'aimerais avoir un emballage qui imite le style du reste de la langue, aussi.

Oui, il y a un tas de choses comme ça pour différentes langues. C# a LINQ, Smalltalk a Roe et GLORP, Python a SQLAlchemy et SQLObject (et Django en Python a un peu de query power built into its ORM (voir Simon Willison's notes), Ruby a ActiveRecord, et ainsi de suite. Je ne sais pas ce que vous utiliseriez en C++, mais je parie qu'il doit utiliser beaucoup de hacking de modèles moche pour les aborder. Tous ces choix peuvent sembler accablants, mais il y a de fortes chances que votre choix de langue soit influencé par autre chose que la commodité de travailler avec des données relationnelles. (Si non, vous devriez considérer Prolog.) Cela vous liera probablement plus ou moins à un ORM que vous détestez comme le reste d'entre nous.

Answer 4

Quince est une bibliothèque C++ qui vous permet d'utiliser la syntaxe C++ et les types C++ avec l'ensemble de fonctionnalités de SQL. Actuellement, il ne supporte que PostgreSQL et sqlite, mais de nouveaux backends peuvent toujours être ajoutés. Voir quince-lib.com. (Divulgation complète: je l'ai écrit.)