Comments 10
Все это дико весело пока не нужно делать поля скажем, valid_period tsrange not null или чтото еще более сложное.
Например у вашего примера есть ссылка на автора, но в некоторых системах считается что ник должен остаться тем, который использовался на момент создания поста. Тогда либо денормализация либо добавление периода действия в таблицу авторов. Хотя почему «или», тут и, без вариантов.
Например у вашего примера есть ссылка на автора, но в некоторых системах считается что ник должен остаться тем, который использовался на момент создания поста. Тогда либо денормализация либо добавление периода действия в таблицу авторов. Хотя почему «или», тут и, без вариантов.
Не раскрыта тема best practics при выборе декларативного или традиционного подхода. Что там получится при m2m?
В другой статье я уже оставил свой комментарий по поводу ORM. Повторю и здесь: на мой взгляд, ORM нисколько не облегчают жизнь (а тем более, не увеличивают эффективность работы с СУБД), поскольку:
1) для схемы БД необходимо потратить время на написание соответствующих классов;
2) внутренняя работа все равно выполняется SQL-запросами;
3) ORM не поддерживают всех функций СУБД (конкретно Postgres);
4) для сложных БД надстройка ORM увеличивает время отклика.
Я пробовал и «алхимию», и PonyORM, и еще много разных, и всегда сталкивался с обозначенными проблемами. В итоге пришел к выводу, что эффективнее просто работать с SQL командами. Часть сложной логики можно переместить на сервер, в виде хранимых процедур / функций.
1) для схемы БД необходимо потратить время на написание соответствующих классов;
2) внутренняя работа все равно выполняется SQL-запросами;
3) ORM не поддерживают всех функций СУБД (конкретно Postgres);
4) для сложных БД надстройка ORM увеличивает время отклика.
Я пробовал и «алхимию», и PonyORM, и еще много разных, и всегда сталкивался с обозначенными проблемами. В итоге пришел к выводу, что эффективнее просто работать с SQL командами. Часть сложной логики можно переместить на сервер, в виде хранимых процедур / функций.
Я бы все-таки в таком случае полностью перешел на хранимые процедуры, чтоб уже все чисто на стороне БД было в таком случае. Хоть хранимки так ненавистные многими, но все еще имеют пару преимуществ.
Кстати, вы сталкивались с Postgres, подскажите не заметили ли вы есть ли заметная разница query или stored procedure optimized execution plans или как перенос кода на хранимые процедуры сказался на производительности?
Кстати, вы сталкивались с Postgres, подскажите не заметили ли вы есть ли заметная разница query или stored procedure optimized execution plans или как перенос кода на хранимые процедуры сказался на производительности?
А pk я привык просто id, для всех таблиц
А это интересный вопрос, я встречал оба варианта и аргументы. Якобы именно на стороне БД конценция писать quote_id вместо id, так как проще потом хранимки и запросы. Личто я бы тоже использовал просто id.
Я тоже чаще использую id в качестве pk. Просто есть библиотеки для SQLAlchemy, например, graphene-sqlalchemy, где id используется как служебное поле и id в таблице затирается, приходится в каждой таблице его переопределять.
С админской частью я вообще не вижу смысла через Python работать. В консоли типа pgAdmin4 все есть :)
Sign up to leave a comment.
Создаем схему базы данных на SQLAlchemy