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

[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

[zelanton.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[zelanton.livejournal.com]

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

[fraks-nsk.livejournal.com]

Триггеры создаются "не тупо"? А надо что бы было "тупо"?

[ext_1684112 (from livejournal.com)]

А не надо использовать FB.

[zelanton.livejournal.com]

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

[ext_1684112 (from livejournal.com)]

> это не стиль
Так делать тоже не надо. Делать исключения только за очень большие деньги.

[zelanton.livejournal.com]

Как делать не надо? Поддерживать старые внедрения не надо? Новомодный стиль "продали, а там хоть потоп"?

[ext_1684112 (from livejournal.com)]

>Новомодный стиль

Что это он новомодный. Очень даже старый.

[zelanton.livejournal.com]

хуяк-хуяк, в продакшен и забыть)

[henu3detb.livejournal.com]

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

[zelanton.livejournal.com]

Лопнет

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

[fraks-nsk.livejournal.com]

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

[vp.livejournal.com]

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

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

[zelanton.livejournal.com]

чёй-та я не понял твоего французкого.
"самого себя инстансов" - это ты сессии что-ли так обозвал? Или шо? А что, у вас кол-во подключений чем-то лимитировано, после цифры 20 например перестаёт работать? Или откуда такие вопросы?

[zelanton.livejournal.com]

если инстансы БД, то я тоже не догоняю откуда подобный вопрос и какое оно имеет отношение к сказанному.

[dennab.livejournal.com]

Завернуть базу в какой-нить один интерфейс не?

[zelanton.livejournal.com]

ORM же + многозвенка, я ядром и развитым API для работы извне.
Заодно снимается необходимость требовать много всяких ненужных BDA длябы оно работало.
А то сначала напишут софт который для маломальско-нормальной работы требует сотню крокодилов, а потом пишут постики про то, что крокодилы у клиентов некачественные.