Каковы жизнеспособные уровни абстракции базы данных для Python

Question

Я начинаю участвовать в проекте с открытым исходным кодом Gramps , который изучает возможность переключения их бэкэнда с BSDDB на реляционную базу данных. Либо SQLite, либо MySQL мы еще не определили полностью и даже можем попытаться сделать и то и другое в некоторой ограниченной емкости Я профессиональный разработчик, но я новичок в Python, поэтому я не очень знаком с текущим выбором инструментов / библиотек. Мне было поручено исследовать слои абстракции БД. В настоящее время идет обсуждение вики для их сравнения. Объектно-реляционный картограф может быть хорошим, но не абсолютно необходимым. хотя я знаю, что это обычно синоним уровня абстракции БД. Если включен ORM, запросы на рекламный хоккей должны быть доступны без особой борьбы.

Прямо сейчас список включает в себя:

CouchDB Я еще не изучал это.

DB-API похоже, это стандартный Python API, и каждый БД создает свой собственный модуль, который его использует. Даже BSDDB, кажется, написал один, но я не полностью исследовал это. взаимозаменяемы ли модули?

SQLAlchemy Это кажется самым популярным сейчас? но у меня очень ограниченное знакомство с миром питонов.

SQLObject Я еще не изучал это.

Так что же представляют и высказывают мнения людей об уровнях абстракции базы данных для python?

Answer 1

Посмотрите очень внимательно на SQLAlchemy.

Вы можете тестировать и разрабатывать с SQLite.

Вы можете начать работу с MySQL - практически не внося изменений в ваши приложения.

DB-API, хотя и широко применяется, обладает достаточной гибкостью, чтобы (1) вы не были изолированы от вариаций SQL в базовой СУБД и (2) все еще есть специфичные для драйвера БД функции, которые трудно скрыть .

Еще один хороший слой ORM - это ORM, который входит в Django . Вы можете (с небольшими усилиями) использовать только Django ORM, не используя остальную часть веб-фреймворка Django.

Используйте слой ORM (SQLAlchemy или SQLObject) вместо предпочтения DB-API.

Почему? Ваша модель должна быть надежной, четкой и продуманной. Реляционное отображение должно идти вторым после объектной модели. SQLAlchemy делает это разумным подходом.

«Уровень абстракции БД» будет происходить в нормальном ходе событий. Действительно, из-за DB-API (как используется SQLAlchemy) вы дали два уровня абстракции: ORM и DB-API.

Answer 2

Доступ к нужной базе данных из Python почти всегда осуществляется с помощью адаптера, совместимого с DB-API 2.0. Хотя все модули DB-API имеют идентичные API (или очень похожи; не все бэкэнды поддерживают все функции), если вы пишете SQL самостоятельно, вы, вероятно, будете писать SQL на специфическом для продукта диалекте, поэтому они не так взаимозаменяемы в практиковаться, как они есть в теории.

Честно говоря, SQLite звучит идеально для вашего случая использования. Я бы не стал беспокоиться о «встроенном MySQL»; это звучит как худшее из обоих миров. Хотите ли вы ORM, такой как SQLAlchemy, полностью зависит от вас; Есть хорошие аргументы в любом случае. Лично мне не нравятся ORM, но у меня есть степень по математике, поэтому тот факт, что я ценю SQL как язык, вероятно, не слишком удивителен:)

Answer 3

CouchDB не является реляционной базой данных, поэтому он не имеет интерфейса DB-API. Это база данных документов, что означает, что она не будет так полезна для Gramps, потому что для выявления связей между связанными людьми потребуются некоторые искажения. Кроме того, он может работать только в режиме клиент / сервер.

Любой ORM, такой как SQLAlchemy, SQLObject или Django ORM, реализован поверх DB-API, и я рекомендую использовать любой из них поверх прямого DB-API, поскольку он может предоставить Gramps гибкость для запуска sqlite во встроенном режиме для локального рабочего стола пользователи, а затем совместно используют, иногда в будущем, соединение базы данных Postgresql / MySQL с веб-версией Gramps.

Answer 4

web2py имеет уровень абстракции базы данных, который можно использовать автономно. Мы переключились между sqlite3, Microsoft SQL Server, Oracle и MySQL с нулевым изменением кода. Впечатлительный.

Answer 5

Мне очень нравится Буря :

Storm - объектно-реляционный картограф (ORM) для Python, разработанный на Canonical. Проект был в разработка более года для использовать в канонических проектах, таких как Панель запуска и недавно была выпущен как продукт с открытым исходным кодом.

По моему мнению, Storm гораздо легче выучить, чем SQLAlchemy. Похож на ORM Джанго.

Answer 6

Я думаю, что CouchDB будет лучшим выбором для такого проекта, как Gramps.

Полезные функции CouchDB для Gramps:

• Нет схемы, нет миграций.

• Поддержка хранения файлов непосредственно в базе данных, например, семейных фотографий и т. Д .: http://guide.couchdb.org/draft/api.html#attachments

• Ubuntu поддерживает CouchDB через настольный компьютер и интегрируется с Ubuntu One для удобного совместного использования или резервного копирования: http://www.freedesktop.org/wiki/Specifications/desktopcouch

• Вы можете легко реплицировать базы данных couchdb, объединить их в одну большую базу данных и т. Д ...

• couchDB очень гибок.

Answer 7

Когда я начал преобразовывать устаревшее приложение для использования ORM, я посмотрел на SQLObject и SQLAlchemy. Сначала я использовал SQLObject, потому что он выглядел знакомым (опыт работы с Django), а SQLAlchemy казался сложным. Примерно через 2 часа я начал бить стены SQLObject. Затем я снова посмотрел на SQLAlchemy и сразу был вознагражден. Он не только понимал и отображал каждую странную таблицу в базе данных, он даже мог выполнять еще более странные поиски, которые мне пришлось делать позже!

Answer 8

Если ваш проект когда-либо будет иметь какую-либо реальную сложность, держитесь подальше от ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx