Попытка выбрать библиотеку SQL API - PullRequest
Новая
       42

Попытка выбрать библиотеку SQL API

2 голосов
/ 22 сентября 2009

Я только начинаю учиться писать программы, которые обращаются к серверу SQL. Кажется, что каждая серверная реализация (Postgres, MySQL и т. Д.) Предлагает библиотеки API для различных языков (мой код написан на C и C ++, хотя решения для Java и Python меня также могут заинтересовать). Однако я немного опасаюсь зависеть от этих библиотек, потому что предпочел бы независимое от поставщика решение.

Насколько я могу судить, API ODBC от Microsoft предназначался для решения таких проблем для C / C ++ (и JDBC для Java); UnixODBC, кажется, одна из популярных реализаций. Я прав до сих пор?

Кроме того, предоставляют ли такие библиотеки объектно-ориентированный интерфейс? Было бы неплохо не просто вставлять SQL-запросы в другой, более функциональный язык; Мне бы хотелось иметь обертку, которая имитирует стиль остальной части языка.

Так есть ли предпочтительное решение в этом направлении? Я спрашиваю о чем-то странном?

Ответы [ 5 ]

1 голос
/ 22 сентября 2009

Насколько я могу судить, API ODBC от Microsoft предназначался для решения таких проблем для C / C ++ (и JDBC для Java); UnixODBC, кажется, одна из популярных реализаций. Я прав до сих пор?

Да. Эквивалент ODBC или JDBC для Python называется DB-API . Эквивалент Perl называется DBI.

Кроме того, предоставляют ли такие библиотеки объектно-ориентированный интерфейс? Было бы неплохо не просто вставлять SQL-запросы в другой, более функциональный язык; Мне бы хотелось иметь обертку, которая имитирует стиль остального языка.

Да, есть множество таких вещей для разных языков. C # имеет LINQ , Smalltalk имеет Roe и GLORP , Python имеет SQLAlchemy и SQLObject (а Django в Python имеет немного мощность запроса встроена в его ORM (см. заметки Саймона Уиллисона )), в Ruby есть ActiveRecord и так далее. Я не знаю, что бы вы использовали в C ++, но держу пари, что для их решения нужно использовать много мерзких хакерских шаблонов.

Все эти варианты могут показаться ошеломляющими, но, скорее всего, выбор языка будет зависеть от удобства работы с реляционными данными. (Если нет, вам следует подумать о Прологе.) Это, вероятно, в большей или меньшей степени связывает вас с каким-то ОРМ, которого вы ненавидите, как и все мы.

0 голосов
/ 14 августа 2018

Посмотрите на Qt. Это не библиотека, а полная структура. У него очень хороший модуль SQL.

Qt SQL является важным модулем, который обеспечивает поддержку SQL базы данных. API Qt SQL делятся на разные слои: 

Driver layer
SQL API layer
User interface layer

http://doc.qt.io/qt-5/qtsql-index.html

0 голосов
/ 18 августа 2014

Quince - это библиотека C ++, которая позволяет использовать синтаксис C ++ и типы C ++ с набором функций SQL. В настоящее время он поддерживает только PostgreSQL и sqlite, но всегда можно добавить новые бэкэнды. Смотрите quince-lib.com. (Полное раскрытие: я написал это.)

0 голосов
/ 22 сентября 2009

Действительно, ODBC / JDBC - это библиотеки, которые помогают сделать интерфейс вызывающего стандарта между поставщиками, но вы правы, что каждая соответствующая СУБД имеет свой собственный вариант SQL. ODBC / JDBC не помогает абстрагировать синтаксис SQL.

Одним из решений для удаления буквенного SQL из кода приложения является реализация запросов в хранимых процедурах, которые находятся в каждом бэкэнде базы данных, а затем использование ODBC / JDBC для вызова хранимых процедур. Вы можете определить хранимые процедуры с похожими именами и интерфейсом вызова для каждой разновидности используемой вами СУБД. Но имейте в виду, что язык хранимых процедур также является переменным от одного поставщика к другому.

Другое решение заключается в использовании технологии «объектно-реляционного отображения», такой как Hibernate для Java или NHibernate для .NET. Эти технологии могут сделать работу с базами данных более «объектно-ориентированной» и во многих случаях избавить вас от написания буквального SQL.

Но большинство инструментов ORM имеют тенденцию фокусироваться на очень простых запросах. Если ваш запрос вообще сложен (например, с использованием GROUP BY или JOIN), использование инструмента ORM на сложнее , чем с использованием литерального SQL.

См. Также " Хорошее ORM для решений C ++? "

Если SQL вас так сильно беспокоит, вы, вероятно, не будете рады использовать RDBMS вообще. Например, некоторые программисты не видят значение Правил нормализации. Если это верно для вас, вы можете посмотреть на новые технологии для нереляционных хранилищ данных, в том числе:

0 голосов
/ 22 сентября 2009

ODBC / JDBC пытаются абстрагировать интерфейс базы данных для обеспечения согласованной модели программирования. Имейте в виду, что, используя такой интерфейс с наименьшим общим знаменателем, вы не сможете воспользоваться конкретными, нестандартными функциями, которые может предложить данная БД.

Чтобы получить объектно-ориентированный интерфейс для вашей модели данных, посмотрите на решения Object Relational Mapping (ORM), такие как Hibernate . Решения ORM отображают ваши объекты на их представление в реляционной базе данных, что значительно упрощает сохранение данных с точки зрения прикладного программирования.

...