может что-то с СУБД не так, если просто так туда бизнес-сущности не вкорячиваются?)

С кодерами не так. Выгодно говнокодить посколько ресурсы компов пока что растут

Сейчас я иногда пишу сложные запросы голые, но когда речь идето простой выборке по условию с парой джоинов, то всегда через ActiveRecord выбираю

Сейчас я иногда пишу сложные запросы голые, но когда речь идето простой выборке по условию с парой джоинов, то всегда через ActiveRecord выбираю

А ActiveRecord PREPARE умеет?

Там под ним слой DAO который делает prepare

А чуть выше слой который выбирает под какую БД загрузить драйвер.

а как оно определяет когда PREPARE нужен а когда нет?

Сейчас я иногда пишу сложные запросы голые, но когда речь идето простой выборке по условию с парой джоинов, то всегда через ActiveRecord выбираю

Тут нюанс в том что SQL-кодер, который эти запросы будет править твоего языка не знает. Поэтому всегда лучше иметь SQL запросы строчные.

а как оно определяет когда PREPARE нужен а когда нет?

Ну когда есть плейсхолдеры в запросе :)

Я надеюсь, что через 10 лет профессия SQL-кодер просто вымрет

Я SQL-кодера за 9 лет карьеры ни разу не встречал :)

Я надеюсь, что через 10 лет профессия SQL-кодер просто вымрет

Лол.

@ttldtor а как проблему будут решать?

Я SQL-кодера за 9 лет карьеры ни разу не встречал :)

Смотря где работать

Вижу тут полное непонимание сути работы с БД, граждане

Смотря где работать

Вот тут мы и подходим к самой сути спора :) Ты своим утверждением что ORM не нужно взял и отмел весь малый да и средний бизнес, оставив только технологических гигантов. Не надо так.

Вот тут мы и подходим к самой сути спора :) Ты своим утверждением что ORM не нужно взял и отмел весь малый да и средний бизнес, оставив только технологических гигантов. Не надо так.

Бизнес измеряется не сложностью схем бд

Имел сложную схему БД трудясь в мелком бизнесе

@ttldtor а как проблему будут решать?

я проблемы не вижу

Ну а где есть SQL кодеры то? Мне кажется это только кровавый энтерпрайз.

Или хайлоад, вот там ORM плохо живет.

норм живёт

Орм не нужно потому что это как кодить с goto - можно, но если проект вырастет то будет ад

ты вообще какие ORM тыкал?)

Ну а где есть SQL кодеры то? Мне кажется это только кровавый энтерпрайз.

В любой конторе где много сложных данных и консистентность данных важна

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

ты вообще какие ORM тыкал?)

Я даже свою писал. Потом в тупик пришёл, посмотрел как у других, поговорил со взрослыми и всё понел

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

Я даже свою писал. Потом в тупик пришёл, посмотрел как у других, поговорил со взрослыми и всё понел

тупик философский или технический?

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

Дело не в размере запроса. Проектирование БД это отдельная профессия. И запросы правильно написать может тот, кто знает схему.

ну там на самом деле куча народу говнокодит пиздец как. переменные транслитом и хардкод параметров в коде это еще цветочки

тупик философский или технический?

Тот что в википедии описан выше

Там описан идеологический случай :)

Но по такой же логике ты должен прочитать вот эту статью https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8 и уйти из программирования вообще, потому что невозможно остановить зависшую программу.

Я ж практик

А не теоретик

Сконструировать сложный select красиво в ООП нереально

А тратить время на Орм из за простых нет смысла

Ну и что? Для таких случаев всегда в ОРМах предусмотрен метод для вызова голого запроса.

А в не-ООП языках?

А тратить время на Орм из за простых нет смысла

Есть и огромный. Как минимум Query Builder экономят кучу времени когда надо сочинять динамически запросы.

А в не-ООП языках?

Sql это вообще язык готовый, зачем прослойки?

Есть и огромный. Как минимум Query Builder экономят кучу времени когда надо сочинять динамически запросы.

Динамические запросы? Подозреваю у вас кривая схема базы

Вот простой пример: юзер хочет в базе искать машины. Иногда он хочет искать по цвету, иногда по цене, а иногда по цвету и по цене. Как это решается голым запросом?

У него в интерфейсе 3 поля - название марки, цвет машины и цена. Иногда он не заполняет 1-2 поля и тогда этот критерий учитывать не нужно.

Условным select

У него в интерфейсе 3 поля - название марки, цвет машины и цена. Иногда он не заполняет 1-2 поля и тогда этот критерий учитывать не нужно.

Запомни этот твит. Приду к компу напишу. И да, тут никакой Орм не нужен

Case when then в условии выборки по каждому полю

Если кратко

То есть ты не считаешь это говнокодом? Такой запрос будет выполняться дольше чем динамически собранный

То есть ты не считаешь это говнокодом? Такой запрос будет выполняться дольше чем динамически собранный

Нет не будет

Case when then в условии выборки по каждому полю

Гоню, просто сложный where

Да это пример простейший, там не должно быть сложных запросов

Запрос не сложный, условие сложнее "обычного". На скорость это точно не повлияет

Другой кейс - у тебя в большой системе есть кучи запросов к автомобилям разные. И в один прекрасный день тебе понадобилось реализовать soft deletable, то есть добавить поле is_deleted BOOL, и везде выбирать только WHERE is_deleted = false В ORM это делается изменением в одном месте модели.

А в БД в 2 местах, но без участия ди кодера вообще

Тебе даже ничего не скажут

Причем оно автоматически будет придумывать алиасы в сложных джоинах и следить за тем чтобы не было конфликтов алиасов.

А в БД в 2 местах, но без участия ди кодера вообще

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

Поэтому в 2 местах. Всякие такие флажки это вообще внутренние детали схемы, прикладным кодерам их знать не надо

Надо, они же бизенс логику реализуют

Таких флажков может быть десяток, всякие колонки статуса и т.д.

Надо, они же бизенс логику реализуют

Я думал этот флажок не бизнес логика а просто какой-то хак

soft deletable это абсолютно реальный паттерн который много где реализуется.

Я сторонник бизнес логику в БД прятать вообще.

soft deletable это абсолютно реальный паттерн который много где реализуется.

Что он даёт?

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

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

Ну ясно, прикладному этот флаг показывать не нужно.

ERROR: S client not available

Как он тогда будет влиять на то учитывать ему флаг или нет?

Это очень частый кейс

Никак - ему отдадут данные уже с учётом этих флагов

Он же должен как-то управлять этим

Где должен там у него возьмут этот флаг.

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

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

Почему это беспокоит ди кодера? Это проблема кодера базы и он знает как это красиво решить. Типовая задача ибо.

Нет денег ни на каких ди кодеров :)

Точнее на кодеров базы

В маленьком стартапчике точно не будет.

А изучить - зашквар? )

Максимум это 1 фронтенд, который делает верстку и JS пишет, и 1 бэкенд который пишет логику и управляет базой и серверами.

А что изучать? Писать голые запросы тупо дольше и в них потом разбираться сложнее. Когда пойдет поток правок и все условия надо будет менять.

Как в резюме sql вписать так у всех, а как реально базу проектировать так Орм и тайные знания кодера 3в1

А что изучать? Писать голые запросы тупо дольше и в них потом разбираться сложнее. Когда пойдет поток правок и все условия надо будет менять.

Изучать СУБД конкретную, хотя они похожи

Ну sql на средне-глубоком уровне бэкендер и так знает. Но знание SQL тебе не даст скорости при переписывании сотен запросов на новую логику.

Мне пофиг но если проект вырастет то его придётся выкинуть и переписать с нуля.

Ну sql на средне-глубоком уровне бэкендер и так знает. Но знание SQL тебе не даст скорости при переписывании сотен запросов на новую логику.

Даст.

Потому что реализация скрыта будет в БД. А данные так и так придётся переносить, так что лучше совместить

Мне пофиг но если проект вырастет то его придётся выкинуть и переписать с нуля.

Ну так и делают, это тоже нормальная практика.

Ну так и делают, это тоже нормальная практика.

Вы определитесь есть у вас деньги или нет)

Вначале денег ни у кого нету

Математическое ожидание от того что качественный код даст проекту взлететь - весьма мало. Поэтому обычно пишут кое как, а потом когда пришел успех то уже нанимают SQL кодеров которые сидят и фултайм оптимизируют запросы.

Но это увы происходит в лучшем случае с 1% проектов.

Математическое ожидание от того что качественный код даст проекту взлететь - весьма мало. Поэтому обычно пишут кое как, а потом когда пришел успех то уже нанимают SQL кодеров которые сидят и фултайм оптимизируют запросы.

Разные есть задачи. Бывает со старта сложная схема

Ну бывает. Тогда может стоит подумать и отказаться от ОРМ, но это не абсолют :)

Вообще ОРМ очень большой процент потребностей покрывает, и если схема реально сложная и он не применим то это вообще повод задуматься, а умеет ли проектировщик проектировать схему и правильно ли он понимает бизнес-задачи )

Схема всегда сложная. Если она простая юзайте... Эксель)

Вообще ОРМ очень большой процент потребностей покрывает, и если схема реально сложная и он не применим то это вообще повод задуматься, а умеет ли проектировщик проектировать схему и правильно ли он понимает бизнес-задачи )

Про сложность неверно.

Короче нефиг прикладными руками в БД лазать)

жизнь показывает другое )

жизнь показывает другое )

?