Подтвердить что ты не робот

Какой вариант выбрать для использования sql в С++

Я хочу подключиться и использовать базу sql в моем приложении C++. Моему приложению необходимо хранить некоторые данные (их можно хранить в виде таблиц), которые будут постоянно расти и должны быть разделены между разными процессами, поэтому мне нужна база данных. Я выбрал sql, потому что он рекомендуется для новичков, и мне нужно несколько сценариев, поэтому нет SQLite.

В процессе поиска я нашел следующие параметры (эти параметры могут включать ORMS, API и Драйверы и могут быть некоторые из этих параметров не должны быть даже включены - то есть я совершенно неправильно понял этот параметр, а затем, пожалуйста, исправьте меня):

Некоторые потоки SO, которые помогают мне найти эти варианты: T1, T2, T3, T4.

Мои вопросы:

  • Какой вариант использовать и когда? Преимущества/Недостатки этих вариантов? (Может основываться на performance, learning curve, compatibility, present support.) Есть ли ориентир или предложение для выбора среди этих параметров. (Я действительно не знаю об этих параметрах, поэтому некоторые из этих параметров могут группироваться вместе, чтобы заставить их работать. Возможно, некоторые из параметров взаимозависимы.)
  • Каков необходимый набор инструментов для этих опций.
  • Если вы используете какую-либо зависимую библиотеку ODBC, то какой ODBC использовать. (Есть много ODBC, упомянутых в ссылке "Некоторые другие" выше.)
  • Любой источник для их изучения. (Для некоторых опций я уже упомянул источник.)
  • Есть ли что-то еще, что я пропустил, полностью?
  • Что делать, если мое приложение находится в C? (Это связано с тем, что мне также необходимо разработать приложение на C, которое использует sql)

Я знаю, что слишком много спросил. Пожалуйста, дайте предложение для какой-либо конкретной части.

4b9b3361

Ответ 1

Основные вопросы, которые вам необходимо учитывать, - это кросс-платформенный интерфейс, который должен быть как на стороне приложения, так и на стороне базы данных.

Если вам нужно подключиться потенциально к нескольким реляционным серверам баз данных (например, Oracle и MySQL или Firebird), вам, скорее всего, будет лучше использовать ODBC (для чего стоит использовать UnixODBC). Я не использовал SQLAPI ++ или SOCI, поэтому я не могу сказать много о том, как они сравниваются с UnixODBC.

С UnixODBC вы получаете довольно большой выбор в развертывании. Довольно часто я вообще не устанавливаю UnixODBC и вместо этого подключаю приложение непосредственно к драйверу ODBC (это полезно, если конкретный экземпляр будет говорить только с одной базой данных и сводит к минимуму все, что вам нужно установить). Он также работает как с С++, так и с C.

С UnixODBC → MS SQL Server мы используем драйвер FreeTDS. Первоначально я беспокоился о том, чтобы начать с этим, но на самом деле я узнал, что проводной протокол полностью указан, поэтому это больше, чем обратный инженерный взлом (а также я считаю, что те же парни, которые делают FreeTDS, также делают коммерческие драйверы EasySoft). MySQL обеспечивает совместимые с UnixODBC драйверы.

Я не пробовал UnixODBC → Oracle, поскольку я уже написал прямой интерфейс OCI (мгновенного клиента), и мы всегда использовали это.

UnixODBC очень немного медленнее, чем использование проводного протокола, такого как OCI, но разница не достаточно значительна, чтобы беспокоиться. Причина, по которой мы используем OCI, заключается в том, что Oracle предоставляет ее бесплатно для платформ Linux/AIX/Solaris, в то время как я не мог найти драйверы ODBC для этих платформ.