Плюсы и минусы использования sqlite3 против реализации пользовательских таблиц

Question

Я заметил, что значительная часть моего (чистого Python) кода имеет дело с таблицами. Конечно, у меня есть class Table, который поддерживает основные функции, но в итоге я добавляю к нему все больше и больше функций, таких как запросы, проверка, сортировка, индексация и т. Д.

Я задаюсь вопросом, будет ли хорошей идеей удалить мой class Table и выполнить рефакторинг кода, чтобы использовать обычную реляционную базу данных , которую я создам в памяти .

Вот мои мысли на данный момент:

1. Производительность запросов и индексации улучшится, но связь между кодом Python и процессом отдельной базы данных может быть менее эффективной, чем между функциями Python. Я предполагаю, что это слишком много, поэтому мне придется использовать sqlite, который поставляется с Python и работает в том же процессе. Я надеюсь это означает, что это чистый выигрыш в производительности (за счет нестандартного определения SQL и ограниченных возможностей sqlite).

2. С SQL я получу гораздо более мощные функции, чем я когда-либо хотел бы кодировать сам. Кажется очевидным преимуществом (даже с sqlite).

3. Мне не нужно будет отлаживать мою собственную реализацию таблиц, но ошибки отладки в SQL трудны, так как я не могу поставить точки останова или легко распечатать промежуточное состояние. Я не знаю, как оценить общее влияние надежности моего кода и времени отладки.

4. Код будет легче читать, так как вместо вызова моих собственных пользовательских методов я буду писать SQL (каждый, кто нуждается в поддержке этого кода, знает SQL). Однако код Python для работы с базой данных может быть уродливее и сложнее, чем код, использующий чистый Python class Table. Опять же, я не знаю, что лучше по балансу.

Есть какие-нибудь исправления к вышесказанному или еще что-нибудь, о чем я должен подумать?

Answer 1

SQLite не запускается в отдельном процессе. Таким образом, у вас фактически нет лишних затрат от IPC. Но издержки IPC не так уж и велики, особенно по сравнению с сокетами UNIX. Если вам нужно несколько программ записи (более чем один процесс / поток записывает в базу данных одновременно), затраты на блокировку, вероятно, будут хуже, и MySQL или PostgreSQL будут работать лучше, особенно если они работают на одной машине. Базовый SQL, поддерживаемый всеми этими тремя базами данных, одинаков, поэтому сравнительный анализ не так уж и болезнен.

Обычно вам не нужно выполнять отладку в операторах SQL того же типа, что и в вашей собственной реализации. SQLite работает и уже довольно хорошо отлажен. Маловероятно, что вам когда-либо придется отлаживать: «Хорошо, эта строка существует, почему база данных не находит ее?» и отследить ошибку в обновлении индекса. Отладка SQL совершенно отличается от процедурного кода, и действительно только когда-либо происходит для довольно сложных запросов.

Что касается отладки вашего кода, вы можете довольно легко централизовать ваши SQL-вызовы и добавить трассировку для регистрации ваших запросов, результатов, которые вы получаете, и т. Д. Интерфейс Python SQLite может уже иметь это (не уверен, я обычно используйте Perl). Вероятно, будет проще всего сделать существующий класс Table оберткой вокруг SQLite.

Я бы настоятельно рекомендовал не изобретать велосипед заново. SQLite будет иметь гораздо меньше ошибок и сэкономит вам кучу времени. (Возможно, вы также захотите взглянуть на недавний переход Firefox на использование SQLite для хранения истории и т. Д., Я думаю, что они получили довольно значительное ускорение от этого.)

Кроме того, хорошо оптимизированная реализация C на SQLite, вероятно, немного быстрее, чем любая реализация на чистом Python.

Answer 2

Вы можете попытаться создать оболочку sqlite с тем же интерфейсом, что и у вашего класса Table, чтобы сохранить свой код в чистоте и получить производительность sqlite.

Answer 3

Если вы работаете с базой данных, используйте базу данных, если нет, то не используйте.Используя таблицы, это звучит как вы.Я бы рекомендовал использовать ORM, чтобы сделать его более питоническим.SQLAlchemy является наиболее гибким (хотя это не просто ORM).