2012-01-16 1 views
4

Причина, по которой я прошу, заключается в том, что мы хотели бы использовать определенное ограничение CHECK, которое MySQL в настоящее время не поддерживает. Без такого ограничения, вся причина использования внешних ключей и ссылочной целостности, по-видимому, уменьшается, так как код приложения берет на себя большую часть обязанностей базы данных.Есть ли какие-либо преимущества в использовании MySQL для чего-либо другого, кроме как «немого» хранилища данных?

Если мы должны были создать «тупую» модель данных и перенести всю проверку ссылочной целостности на уровень в коде приложения, то потенциальное тестирование может быть проще, поскольку ошибки ссылочной целостности будут захвачены в приложении, а не дб. Это может также потенциально ускорить разработку новых модулей, так как они не обязательно должны были бы быть полностью завершены (это термин?) Перед тестированием.

Итак, есть ли какие-либо другие преимущества, связанные с «правильной» моделью данных в MySQL и хранением внешних ключей и «ON UPDATE CASCADE» и т. Д.?

Или, если мы перевернем MySQL и перейдем к чему-то еще ?!

Спасибо!

+1

Я думаю, что ссылочная целостность немного отличается от ограничений проверки. – newtover

+0

@newtover, конечно, они разные - мы просто не видим преимуществ использования RI, когда мы не можем получить подтверждение, но мы могли бы иметь оба, если бы все они были в приложении ... – Bendos

+1

Если вы привержены использовать бесплатное программное обеспечение (как в пиве), вы считали [PostgreSQL] (http://www.postgresql.org/docs/8.1/static/ddl-constraints.html)? –

ответ

7

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

Что касается меня в отношении переноса ограничений (и другой бизнес-логики) из базы данных, так это то, что труднее всего применять ограничения везде. Каждый разработчик в каждом отдельном приложении может нарушить это ограничение. Администратор базы данных также не может помочь.

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

+7

Том Ките (Oracle Expert) сказал это довольно красиво один раз: «* Ваше приложение не будет единственным, и оно не будет последним, чтобы использовать эти данные *» (если эти данные имеют какое-либо значение) –

+0

Спасибо @DOK, я знаю, что вы правы, но, возможно, стало общим думать, что администраторы баз данных - это разные люди от разработчиков ... По моему опыту (в небольших проектах, если честно!), они являются одним и тем же человеком и поэтому так же способны уничтожать базу данных, как и приложение :) – Bendos

0

Да, если вам нужна функция, которая не поддерживается MySQL, тогда вы можете перейти к чему-то еще.

2

Вы можете эмулировать проверочное ограничение другими способами

  • Trigger
  • FK в одной строке таблицы
  • Одно значение перечисления

Это неудобно, но не конец Мир.

В любом случае не все ограничения могут или должны быть выполнены в приложении. Уникальность? Проверки нулевой суммы (например, баланс = ноль перед деактивацией учетной записи).

Это ваши данные и ваш беспорядок убирать, когда он идет не так ...

+0

Привет @gbn, спасибо за ваши комментарии. Мы рассмотрели использование триггеров для некоторых проверок проверки, но они всегда казались запоздалой мыслью по сравнению с истинными CHECK. Я знаю о рисках потерянных записей, обновлении аномалий и т. Д., Если db не поддерживает свою собственную целостность, но я не говорю об удалении полностью - просто переключая его на другой уровень. Как я упоминал в комментарии DOK, довольно часто DBA _is_ разработчик, поэтому это его/ее беспорядок, какой бы механизм они ни использовали! – Bendos