Как важный похожи на ограничения NOT NULL и FOREIGN KEY, если я буду всегда управлять своим входом базы данных с PHP?

Я боюсь, что это - религиозная тема.

С puristic точки зрения, Вы хотите, чтобы база данных сделала ссылочную целостность. Это идеально, когда у Вас есть разнообразие приложений, получающих доступ к базе данных, потому что ограничения находятся в одном месте. К сожалению, реальный мир не идеален.

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

, Поскольку заметка на полях, настраивая MySQL для поддержки ограничений внешнего ключа является определенным процессом, потому что необходимо сместиться к InnoDB. Если Вы делаете всего , что, можно вернуть большую производительность установкой innodb_flush_log_at_tx_commit к 1. Но, вероятно, было бы лучше, если можно вместо этого повторно спроектировать сайт для транзакции. Тогда Вы извлекаете две пользы из InnoDB.

Я высоко ценю Ваш вопрос, поскольку я глубоко убежден, что правила значения по умолчанию должны быть реализованы на стороне кода, не на стороне базы данных и этом по очень простой причине: то, когда пользователи являются тем, которые инициируют изменения базы данных (ВСТАВЛЯЕТ, ВЫБИРАЕТ и ОБНОВЛЯЕТ), эти изменения должны интегрировать все бизнес-правила, и значения по умолчанию являются в основном бизнес-правилами:

• нет никакого счета без номера счета-фактуры
• нет никакой строки счета без количества, и 0, или пустые указатели не приемлемы
• нет никакой входящей корреспонденции без даты приема
• и т.д.

, Мы решили несколько лет назад избавиться от всех этих артефактов "стороны базы данных" как "не пустой", "(не делают) позволяют пустые строки" и другие приемы "значения по умолчанию", и это работает отлично. Аргументы в пользу значения по умолчанию главным образом относятся к своего рода принципу "безопасности" ("делают это на стороне базы данных, потому что Вы забудете к нему на стороне кода / Ваш язык не сделан для that/it's, легче сделать это на стороне базы данных"), который не имеет никакого смысла, как только Вы приняли решение не реализовать любое значение по умолчанию на стороне базы данных: просто проверьте, что Ваши бизнес-правила правильно реализованы при отладке.

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

РЕДАКТИРОВАНИЕ: перечитывая некоторые ответы здесь, мой заключительный комментарий был бы: сделайте это на любой стороне, или DB или кодируйте, но сделайте Ваш выбор и сделайте это на одной стороне только! Нет ничего более опасного, чем наличие таких средств управления с обеих сторон, потому что в конечном счете (1) Вы никогда не будете знать, реализуют ли обе стороны действительно то же правило, подразумевая, что (2) проверка правил будет означать проверять обе стороны, которые могут действительно стать путаницей! Худшая ситуация состоит, конечно в том, когда одна часть задания сделана на стороне базы данных (т.е. правила, которые были определены, когда база данных была создана), и другая часть (т.е. недавно identitified правила) сделанный на стороне клиента... кошмар....

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

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

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

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

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

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

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

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

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

Моя рекомендация состоит в том, чтобы выбрать различный RDBMS.

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

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

По Вашему вопросу о NOT NULL... Очевидные требования поля данных являются хорошей начальной точкой. Вот несколько других вещей рассмотреть при определении столбца nullability.

Это обеспечивает гарантию, которая может очень полезный при записи запросов. Различные соединения могут использовать ПУСТЫЕ условия показать несоответствие строки таблицы, отдельной от Нулевого значения, которое не может быть принято, если условие позволяет, аннулирует. (Если ПУСТЫЕ УКАЗАТЕЛИ позволяются, соответствие может означать, что или строка не соответствовала или строка, действительно соответствовал, но значение столбца является пустым.)

использование NOT NULL также помогает определить правила для более простых совпадающих значений запросов. Так как Вы не можете сказать, "КОГДА value1 = value2", если и value1 и value2 являются ПУСТЫМИ результат оценки, является все еще ложным.

Я обычно выступаю за объявление ограничений в базе данных. Аргументы в пользу ограничений:

• Декларативный код легче сделать без ошибки, чем Обязательный код. Ограничения осуществляются, даже если код приложения содержит ошибки.
• Поддержки "не Повторяют Себя" принцип, если Вы имеете несколько приложений или кодируете модули, получающие доступ к той же базе данных, и Вам нужны бизнес-правила, которые будут осуществлены однородно. Если необходимо изменить ограничение, можно сделать это в одном месте, даже если у Вас есть много приложений.
• Осуществляет целостность данных, даже когда люди пытаются обойти приложение, с помощью инструментов специального запроса для переделывания базы данных.
• Осуществляет непротиворечивость , что означает, что можно всегда быть уверены, что данные находятся в допустимом состоянии прежде и после любого обновления данных. Если Вы не используете ограничения, Вы, возможно, должны выполнить периодические запросы, чтобы проверить на поврежденные ссылки и очистить их.
• можно смоделировать, каскадное обновление / удаляют легко с ограничениями. Выполнение того же самого в коде приложения сложно и неэффективно, не может применить изменения атомарно (хотя использование изоляции транзакции рекомендуется), и восприимчиво к ошибкам.
• Ограничения помогают базам данных больше самозарегистрировать, так же, как имена столбцов и справка типов данных SQL.

Аргументы против ограничений:

• более сложные бизнес-правила не могут быть смоделированы декларативными ограничениями, таким образом, необходимо реализовать некоторых в пространстве приложения так или иначе. Учитывая, что, почему бы не реализовать все бизнес-правила в одном месте (Ваше приложение) и на том же языке? Это облегчает отлаживать, тестировать, и отслеживать изменения кода.
• Ограничения часто включают индексы, которые подвергаются некоторой сумме издержек во время, вставляет/обновляет. С другой стороны, даже если Вы не объявляете ограничение, Вам, вероятно, нужен индекс так или иначе, потому что столбец может использоваться в критериях поиска или условиях объединения часто.
• Ограничения могут усложнить Ваши попытки "очистить" ошибки в данных.
• В Вашем текущем проекте, несовместимость MyISAM по сравнению с InnoDB относительно ограничений по внешнему ключу вызывает некоторое горе.

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

Имеют в виду, что виды ошибок, от которых Вы сохраните себя, могут быть довольно противными. Нахождение и исправление самой ошибки не могут быть трудными; противная часть то, что, как только Вы исправили ошибку, которую Вам оставят с набором дефектных данных, которые даже не могут быть salvageable.

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

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

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

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

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

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

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

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

Они довольно важны. Вы не хотите определять свою модель полностью через PHP. Что, если существует ошибка в Вашем коде PHP? У Вас могли легко быть null'ed столбцы, где Ваши бизнес-правила указывают, что Вы не должны. Путем определения его на уровне базы данных Вы, по крайней мере, получаете ту проверку бесплатно. Вы собираетесь действительно ненавидеть его, когда существуют ошибки в Вашем PHP или если какой-либо другой инструмент когда-нибудь использует Вашу базу данных. Вы просто просите проблему, по моему скромному мнению.

рекомендоваться, это - очень короткая версия истории.

Используйте базу данных для структурной целостности данных и используйте уровень BR для остальных. И зафиксируйте ошибки как можно раньше. Они сотрудничают.

С удачей, когда Ваш код, как назрели, Вы не столкнетесь с databse ошибками RI; и можно гордо объявить о себе, чтобы быть первыми.

Даже если в вашем PHP-коде нет ошибок, он может остановить выполнение сценария в середине (ошибка нехватки памяти, segfault в какой-то библиотеке и т. Д.), Оставляя в базе данных наполовину вставленные данные, отсюда важность использования InnoDB и транзакций.

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

Ограничения базы данных легко указать, поиск ошибок в приложении - это

Мой опыт показал, что базы данных с неправильными ограничениями и все, что использует MyISAM, БУДУТ иметь несоответствующие данные после нескольких месяцев использования, и очень трудно найти, откуда они.