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

Я заметил, что wordpress /rails и т. д. не используют ограничения внешних ключей или каскадные функции удаления из базы данных. Вместо этого они обрабатывают это на уровне PHP /Ruby /scripting!

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

Предполагая, что аргументы против внешних ключей действительны, мой вопрос:

  1. Если внешние ключи плохие, почему WordPress /Rails /etc использует sql-сервер, который поддерживает внешние ключи? Удастся ли им уйти от MySQL к серверу NoSQL?
  2. С другой стороны, могут ли приложения, закодированные таким образом, чтобы использовать функцию внешних ключей без проблем?
  3. Является ли noSQL /redis лучше, если мы используем базу данных только для хранения и управления «отношениями» на уровне приложения /сценария?
6 голосов | спросил rahul286 12 J0000006Europe/Moscow 2013, 09:42:28

1 ответ


12

Давайте начнем с вашей первой ссылки. Он четко говорит:

  

Работа с большими базами данных с ссылочной целостностью просто не работает.

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

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

  

Принесут ли они пользу от перехода от MySQL к серверу NoSQL?

Вряд ли. Они полезны, когда профессионал использует их по мере необходимости.

  

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

Да.

  

Является ли noSQL /redis лучше, если мы используем базу данных только для хранения и управления отношениями,   на уровне приложения /сценария?

Я однажды просмотрел приложение для обновления технологии в банке, который не использует ссылочную целостность (чтобы повысить производительность). Загрузка данных в SQL Server (который должен был заменить их устаревшую установку Adabas), он потерпел неудачу с нарушениями ограничений целостности. Случается, что 40% исторических записей были недействительными, поскольку некоторые * удалили значения таблицы поиска, которые больше не используются (например, старые классификационные коды клиента, которые были заменены для всех активных клиентов, а не старые ). Предупреждение целостности ссылочной целостности не появилось. В результате были некоторые уволенные люди, и проблема застряла в обходном пути, а частично бесполезный склад данных построен сверху.

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

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

ответил TomTom 12 J0000006Europe/Moscow 2013, 10:59:36

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132