Как стать автором
Обновить

Комментарии 10

Все это дико весело пока не нужно делать поля скажем, valid_period tsrange not null или чтото еще более сложное.

Например у вашего примера есть ссылка на автора, но в некоторых системах считается что ник должен остаться тем, который использовался на момент создания поста. Тогда либо денормализация либо добавление периода действия в таблицу авторов. Хотя почему «или», тут и, без вариантов.
Планируется сервис поиска цитат, возможность добавления только у админа, а авторами будут не пользователи, а известные личности.
Если известные личности тут таки да.
Не раскрыта тема best practics при выборе декларативного или традиционного подхода. Что там получится при m2m?
В другой статье я уже оставил свой комментарий по поводу ORM. Повторю и здесь: на мой взгляд, ORM нисколько не облегчают жизнь (а тем более, не увеличивают эффективность работы с СУБД), поскольку:
1) для схемы БД необходимо потратить время на написание соответствующих классов;
2) внутренняя работа все равно выполняется SQL-запросами;
3) ORM не поддерживают всех функций СУБД (конкретно Postgres);
4) для сложных БД надстройка ORM увеличивает время отклика.
Я пробовал и «алхимию», и PonyORM, и еще много разных, и всегда сталкивался с обозначенными проблемами. В итоге пришел к выводу, что эффективнее просто работать с SQL командами. Часть сложной логики можно переместить на сервер, в виде хранимых процедур / функций.
Я бы все-таки в таком случае полностью перешел на хранимые процедуры, чтоб уже все чисто на стороне БД было в таком случае. Хоть хранимки так ненавистные многими, но все еще имеют пару преимуществ.

Кстати, вы сталкивались с Postgres, подскажите не заметили ли вы есть ли заметная разница query или stored procedure optimized execution plans или как перенос кода на хранимые процедуры сказался на производительности?
Повторю и здесь: на мой взгляд, ORM нисколько не облегчают жизнь (а тем более, не увеличивают эффективность работы с СУБД)

нужно наверно оговориться, что речь идет о клиенткой стороне приложения, потомучто как с админкой без орм работать, этож боль, для каждой модели данных надо будет 4 типовых запроса select,delete,update,insert.

Не первый раз вижу, что pk в алхимии делают по имени самой таблицы quote_id для quote, author_id для author, это удобно? У меня такие ключи всегда ассоциируются с fk. А pk я привык просто id, для всех таблиц
А pk я привык просто id, для всех таблиц

А это интересный вопрос, я встречал оба варианта и аргументы. Якобы именно на стороне БД конценция писать quote_id вместо id, так как проще потом хранимки и запросы. Личто я бы тоже использовал просто id.
Я тоже чаще использую id в качестве pk. Просто есть библиотеки для SQLAlchemy, например, graphene-sqlalchemy, где id используется как служебное поле и id в таблице затирается, приходится в каждой таблице его переопределять.
С админской частью я вообще не вижу смысла через Python работать. В консоли типа pgAdmin4 все есть :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории