Каковы жизнеспособные уровни абстракции базы данных для Python
У вас фактически есть та же самая проблема в каждом из ваших утверждений if. Когда вы пишете что-то вроде
if response_1 == "Yes" or "yes"
, python интерпретирует это как
if (response_1 == "Yes") or ("yes")
То есть: если переменная response_1 равна «Да», или если строка «да» верна , тогда оператор if выполняется. «да» - это правда, поэтому утверждение if всегда выполняется. (См. здесь , например, для получения дополнительной информации о том, что означает правдивость).
Что вы, вероятно, хотели, чтобы проверить, равна ли переменная response_1 «Да» или «Да», что записывается как:
if response_1 == "Yes" or response_1 == "yes"`
И, конечно, вам нужно применить это же исправление к остальным вашим утверждениям if.
6 ответов
Взгляд очень тесно на SQLAlchemy.
Можно протестировать и разработать с SQLite.
Можно войти в производство с MySQL - делающий по существу изменения в приложениях.
У DB-API, в то время как широко придерживается - к, есть достаточно гибкости, которая (1) Вы не изолируетесь от вариации SQL в базовом RDBMS и (2) существует все еще DB определенные для драйвера функции, которые трудно скрыть.
Другой хороший уровень ORM является ORM, это - часть Django. Вы можете (с небольшим усилием), используют просто Django ORM, не используя остальную часть веб-платформы Django.
Используйте Слой ORM (SQLAlchemy или SQLObject) в предпочтении к DB-API.
Почему? Ваша модель должна быть телом, четкой, хорошо продуманной моделью OO. Реляционное отображение должно прийти вторым после объектной модели. SQLAlchemy делает это разумным подходом.
"Уровень абстракции DB" произойдет в нормальном ходе событий. Действительно, из-за DB-API (как используется SQLAlchemy) Вы дали два уровня абстракции: ORM и DB-API.
Доступ к надлежащей базе данных из Python почти всегда делается с помощью DB-API 2.0-совместимый модуль адаптера. В то время как все модули DB-API имеют идентичные API (или очень похожий; не все бэкенды поддерживают все функции), если Вы запишете SQL сами, то Вы будете, вероятно, писать SQL на определенном для продукта диалекте, таким образом, они не будут столь же взаимозаменяемыми на практике, как они находятся в теории.
Честно, SQLite звучит идеально подходящим для Вашего варианта использования. Я не обеспокоился бы "встроенным MySQL"; это походит на худший из обоих миров. Хотите ли Вы ORM как SQLAlchemy, полностью ваше дело; так или иначе существуют хорошие аргументы. Лично, мне не нравится ORMs, но затем у меня есть математический градус, таким образом, то, что я ценю SQL как язык, вероятно, не слишком удивительно :)
CouchDB не является реляционной базой данных, таким образом, он не имеет API-ИНТЕРФЕЙСА DB. Это - документная база данных, что означает, что это не было бы столь же полезно для Дедули, потому что это потребует, чтобы некоторые искривления определили ссылки между связанными людьми. К тому же это может только работать в клиент-серверном режиме.
Любые ORM как SQLAlchemy, SQLObject или Django ORM реализованы сверху DB-API, и я рекомендую использовать любой из них по прямому DB-API, потому что он может дать Дедуле гибкость, чтобы выполнить sqlite во встроенном режиме для локальных настольных пользователей и затем затем совместно использовать, когда-то в будущем, соединение с базой данных Postgresql/MySQL с веб-версией Дедули.
Мне действительно нравится Storm:
Storm является объектно-реляционным картопостроителем (ORM) для Python, разработанного в Каноническом. Проект был в разработке больше года для использования в Канонических проектах, таких как Панель запуска и был недавно выпущен как продукт с открытым исходным кодом.
По-моему, Storm намного легче изучить, чем SQLAlchemy. Подобно ORM Django.
Если Ваш проект будет когда-либо иметь реальную сложность, держитесь подальше от ORMs.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Когда я начал преобразовывать приложение прежней версии для использования ORM, я изучил SQLObject и SQLAlchemy. Сначала я пошел с SQLObject, потому что это выглядело знакомым (мимо опыта Django), и SQLAlchemy казался сложным. Приблизительно после 2 часов я начал врезаться в стены с SQLObject. Я затем посмотрел на SQLAlchemy снова и был немедленно вознагражден. Мало того, что это понимало и отображало каждую странную таблицу в базе данных, это даже могло сделать еще более странные поиски, которые я должен был сделать позже!