Есть ли смысл в нативных связях в БД, если relation в active record их дублируют?

Question

[Evgeny_Shestakov]

При проектировании БД делаю связи между таблицами - это удобно как для визуального восприятия, так иногда и технически, например при каскадном удалении по внешнему ключу связанных данных. Понятно что так делать грамотно, но в случае с Yii (Yii 2), мы их (на уровне БД) в любом случае дублируем на уровне бизнес-логики приложения (да при автогенерации кода создаются методы-связи), но возникает вопрос: а почему бы тогда не оставить всю логику на уровне приложения (php), как мне кажется так будет проще работать, а базу использовать как хранилище несвязанных таблиц (на уровне БД).

Есть ли смысл в нативных связях в БД, если relation в active record их дублируют?

Answer 1

[Дмитрий Евграфович]

Не стоит, если для вас сейчас это очевидно, это не значит, что оно останется очевидным через год или будет очевидным для того, кто в будущем вместо вас будет поддерживть код. В дополнение к этому вам придется написать подробную документацию к своему коду (проставить внешние ключи гораздо проще, чем описать 100 кусков кода, которые нужно учитывать просто потому, что ключи не проставлены), а вашему сменщику ее тщательным образом изучить перед началом работы и более того - постоянно держать в памяти. Не знаю как в yii, но в laravel с базой можно работать посредством Orm eloquent и query builder. В eloquent я еще могу описать некоторые правила, но у меня нет гарантий, что программист, который будет работать над проектом после меня не решит использовать query builder, обойдя стороной все всю логику, записанную в моделях. И и в случае с целостностью базы это проблемы не только программиста, это проблемы в первую очередь проекта. Php не надает по рукам такому программисту, а вот база данных запросто.

Comments

[65536]

так и не понял в пользу чего вы ответили)

[Дмитрий Евграфович]

65536: тогда сократите мою простыню до первых двух слов, с которых она начинается :)

[Александр Макаров]

Другими словами, смысл есть.

[Дмитрий Евграфович]

Александр Макаров: другими словами "не стоит". Но если вы считаете, что внешние ключи - это не нужная в базах данных вещь и целостность данных можно отдать на откуп только php - с удовольствием выслушаю аргументацию человека с вашим опытом разработки :)

[Evgeny_Shestakov]

Дмитрий Евграфович: Правильно ли понимаю (из слов "не стоит") что конкретно в Yii вы считаете связи в БД можно не использовать, но в принципе вы за их использование? Александр Макаров - правильно ли понимаю что плюсом использования связей и внешних ключей будет "целостность данных" и удобство каскадного удаления средствами БД, т.е. уменьшение кода в afterDelete, есть ли еще "бонусы" от Yii за связи в БД (кроме связей формируемых gii) ?

[Дмитрий Евграфович]

Evgeny_Shestakov: Нет. Я считаю, что необходимо использовать внешние ключи в самой базе данных независимо от используемого фреймворка и того, следит он за целостностью или не следит. Я видимо вчера слишком запутанно написал, сейчас выскажу свое мнение проще: если вы полагаетесь только на фреймворк, то после вас обязательно придет дурак, напишет свой метод на голом PDO и все испортит.

[Александр Макаров]

Дмитрий Евграфович я считаю, что внешние ключи необходимы. Вопрос был «Есть ли смысл в нативных связях в БД?». Ответ на него «смысл есть». Ответ «не стоит» воспринимается как «не стоит делать нативные связи».

[Александр Макаров]

Evgeny_Shestakov правильно. Дополнительных бонусов нет. Этих уже достаточно.

[Дмитрий Евграфович]

Александр Макаров: черт, я ступил отвечая тебе. сорри :) "не стоит" было в значении - не стоит доверяться только фреймворку.

[Дмитрий Евграфович]

Александр Макаров: Просто мысль зацепилась за фразу "а почему бы тогда не оставить всю логику на уровне приложения (php)". Если кто-то посчитал, что не стоит - это ответ на заголовок, приношу всем свои извинения.

Answer 2

[nirvimel]

Хорошие ORM всегда выстраивают в базе полную структуру связей со всеми Constrainments и Foreign keys.

Answer 3

[MegaMufa]

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

Если же вы выставите ключи, то бд сама будет следить за целостностью. Она не даст вам записать неконсистентные данные и при удалении каскадно удалит все "осиротевшие" записи (если ключ этого требует).

Плюс каскадное удаление бд сделает быстрее, чем ваш код. Вы например удаляете пользователя и надо удалить все его записи. Вам для этого сначала придется выбрать все его записи. Удалить их. А уже потом удалить пользщователя. А в внешними ключами вы просто удаляете пользователя, а бд сама подчистит все зависимые записи.

Comments

[MegaMufa]

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

[65536]

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

[MegaMufa]

65536: А я и не говорил, что это единственный критерий целостности. Но обязательный. Вопрос был: "Надо ли использовать ключи, если связи все равно дублируются в коде?" Я ответил, что да, стоит.

>> Если мы готорим только о БД, то есть тригеры. Если мы говорим о системе в целом, то это делается в моделях, но к бд это уже не имеет никакого отношения.

>> я думаю более универсальный вариант когда база располагается намертво за заданным апи. то есть никаких редактирований в обход вообще
Тут я с вами полностью согласен. Это буедт идеальный вариант. Но есть куча тонкостей. Например огромные запросы, для которых лоигку надо в хранимки выносить. Тут уже логика в модели не поможет. Или в стадии активной разработки часто надо ручками данные менять.

Вообще это очень обширный вопрос разделения логики между приложением и базой. Это плодотворная тема для холиваров и немало копий было сломано в спорах на эту тему. Поэтому я еще раз подчеркну, что я согласен с вами: ключи обязательное средство, но не единственное.

[65536]

HaruAtari: признаться, никогда не пробовал бд связи использовать. в основном из соображений того, чтобы не размазывать логику между кодом и какой-то фичей субд. лучше все будет в одном месте и наглядно (на правоту даже не претендую))

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

[MegaMufa]

65536: Накладок не будет, если при проектировании кода вы это учтете.

Например: у вас есть покупателей и модель заказов, связанные AR связью и ключем в бд. При удалении покупателя вам надо удалить его заказы. А при удалении заказа, который еще не был отправлен, надо увеличить счетчик товара на складе.

Как это выглядит? В Customer::afterDelete() вы выбираете все его заказы, проверяете, какие из них не были отправлены увеличиваете соответствующий им счетчик. Без ключей этот подход прекрасно работает.

Если же у вас будет использоваться удаелние по ключу, то такой подход не сработает т.к. на момент срабатывания afterDelete() заказов пользователя уже не буедт в бд (база их удалит вместе с пользователем). Поэтому эту обработку надо выполнять в Customer::beforeDelete(), после всех проверок. Тогда все нормально будет работать.

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

Плюс ключи помогают еще и при записи. В этой же схеме бд не даст вам создать заказ, для которого указан id-гник несуществующего покупателя.

>> признаться, никогда не пробовал бд связи использовать. в основном из соображений того, чтобы не размазывать логику между кодом и какой-то фичей субд. лучше все будет в одном месте и наглядно (на правоту даже не претендую))

Во-первых: это не какая-то фича, а сама суть реляционной(!) бд. Плюс чтобы вы не размазываете логику, она вся в вашем коде. Ключи нельзя назвать логикой работы. База просто гарантирует целостность данных в ней.

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

Answer 4

[mitaichik]

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

И аккуратней с каскадным удалением. Частенько при удалении должна отработать какя-то дополнительная логика, например в том же afterDelete. При каскадном удалении оно идет на уровне бд, а не на уровне приложения, поэтоу логика не отрабатывает.