Рельсы и констрейнты в БД

[metaclass]

http://guides.rubyonrails.org/migrations.html#active-record-and-referential-integrity
"The Active Record way claims that intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database, are not heavily used."

В ActiveRecord червь не рекомендует делать констрейнты в БД. Это огорчение, т.к. например, я сломал к хуям (т.е. до невозможности вообще хоть что-либо сделать из UI) хипстерское веб-приложение одним SQL-запросом :)

Comments

[sergiej.livejournal.com]

С констрейнтами практически всегда больше проблем чем помощи. Если вдруг хочется оставить контроль базе, то потом блин всё равно позаботься завернуть вылетевший на базе констрейнт эксепшн в логику приложения, а это никак не меньше работы чем позаботиться о данных до попытки запихнуть их тупо.

[bydlorus.livejournal.com]

С обработкой ошибок всегда больше проблем чем помощи :-)

[sergiej.livejournal.com]

Ну можно конечно не обрабатывать, а тупо показать юзеру или бросить обратно по интерморде. Но не думаю что юзер будет доволен таким оборотом событий

[bydl0coder.livejournal.com]

Есть еще уличная магия - обработать и показать нетупо. Не все владеют, конечно.

[sergiej.livejournal.com]

Но возни с этим столько, что имхо в большинстве случаев проще побеспокоиться о качестве данных ДО инсертов.
Постоянно сталкиваюсь с ситуацией, когла приложение "ожидало" что на базе будет констрейнт. Потом криворукие снимают консрейнт, потому что бизнес задолбал и "разрешил" дубли, потому что могут, а в приложение залезть не могут. Так что обработка консистентности данных на уровне приложения это ещё и буфер от хитрозадых бизнесов

[bydlorus.livejournal.com]

А можно в вызовах библиотеки входные параметры не проверять и ArgumentException не кидать, т.к. "придётся позаботиться завернуть вылетевший эксепшн в логику приложения, а это никак не меньше работы чем позаботиться о данных до попытки передать их тупо."

Т.е. логика немного кривая. Забота о целостности данных должна быть везде. Если мы, конечно, говорим о referential integrity а не о проверке возвраста пользователя в триггерах.

[sergiej.livejournal.com]

Если в дополнение к проверке приложением есть ещё и констрейнт то я не против, если конечно на производительность не влияет, при больших таблицах - влияет.

[henu3detb.livejournal.com]

Лучше пусть в продакшне будет необработанный эксепшн, чем неконсистентные данные, которые боком начнут вылазить через пол года на другой машине на другом континенте. Вот тогда будет точно ребус, откуда оно.

[sergiej.livejournal.com]

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

[bydlorus.livejournal.com]

Вообще-то FK - это метаданные, которые зачастую сами по себе весьма полезны. По ним можно генерить всякую инфу. Например, я как-то писал прогу, которая из базы выдирает только данные, связанные с определённым проектом - от таблицы Projects по FK расходилась выборка нужного (анальные корпоративные правила не позволяли высылать всю базу).

[sergiej.livejournal.com]

Если правильно сделана система связывания по ФК, то всё будет ок без констрейнтов. Опять же обязательное условие чтобы никто в базу ручками не лазил чтобы что-то по-быстряку инсертнуть

[henu3detb.livejournal.com]

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

[sergiej.livejournal.com]

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

[metaclass.livejournal.com]

Констрейнты что до базы (в UI), что после базы обрабатываются достаточно однообразно, главное сунуть обработчик в точку через которую запросы ходят.
Зато при их наличии гарантированно, что внешние псы ходящие в базу, приложение не попортят.

[sergiej.livejournal.com]

" что внешние псы ходящие в базу, приложение не попортят."
Расстреливать сразу

[bydlorus.livejournal.com]

Legacy?

[sergiej.livejournal.com]

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

[fraks-nsk.livejournal.com]

Гм... Вообще-то люди не идеальны, в том числе и вы. Констрейнты позволяют максимально просто и быстро объявить ограничения со 100% их соблюдением. А в приложении оно будет реализовано не сразу, забыл, не подумал, отвлекся, "потом"...

[sergiej.livejournal.com]

так я же соглашаюсь, как временные костыли и как последняя инстанция для прикрытия задницы - очень даже, но не как основа логики приложения.

[zelanton.livejournal.com]

А потом удаление записей превращается в ебанный секс, когда структура данных превращается в сеть, где объекты сами на себя ссылаются через 10 разных путей. И хуячь триггеры, процедуры, получай вендор лок. Особенно пиздато, когда в каком-нибудь оракле от всех этих триггеров и процедур приползают блокировки страниц или другое подобное веселье. Или тот же MSSQL с ограничением вложенности рекурсии.

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

[metaclass.livejournal.com]

Рекурсивные зависимости в базе?

[zelanton.livejournal.com]

ну. Кстати у FB с этим беда (многие триггеры не тупо создаются, уж не помню с какими формулировками). Если я ничего не путаю, а могу, т.к. натрахавшись с триггерами я на них уже забил и делаю кодом - в каждой СУБД свои уникальные грабли, превращающие кросплатформенную работу с тригерамми в кромешный адъ. Только код, а заодно никакого вендор-лока. Но там свои грабли)

[henu3detb.livejournal.com]

А вот не надо ничего удалять )

[zelanton.livejournal.com]

Лопнет

может например удалятся через настраиваемое время (n-лет) после пребывания в статусе "как бы удалено". Или вообще не удаляться. Это уж как юзеру угодно будет, схему жизненного цикла объекта пускай правит, где-то оно надо, где-то - мешает, по ситуации. Но вообще сама возможность удаления в ситуация когда связей уже пиздец сколько и oracle/mssql ебанётся на каком-нибудь случае.

[vp.livejournal.com]

"никого в базу не пускать"

А самого себя инстансов так 100 если, да все на одну базу?