Вы когда-нибудь работали с базой данных без «Отношений», без «ПК» и без «ФК», только с необработанными данными?

Question

В настоящее время я работаю над базой данных без "Отношений, ПК и ФК", просто необработанные данные. Я могу сказать, что база данных - это просто набор документов. Когда я спросил об этом, у меня было это; «Скрыть бизнес».

Кроме того, один из моих друзей сказал, что это всегда происходит в «Больших системах».

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

Что вы думаете об этом?

Answer 1

Что ж, этот может иметь смысл для больших баз данных, когда вам нужно быстрый ответ на массовый DML (INSERT / UPDATE / DELETE).

Проблема в том, что если вы полагаетесь на способ обеспечения целостности базы данных, вы вряд ли сможете ее оптимизировать.

Существует также вещь, называемая SQL/PLSQL context switching в Oracle: если вы создадите пустой триггер на столе, он замедлится DML примерно в 20 раз - просто потому, что триггер существует.

В Oracle, когда вы пишете триггер ON UPDATE и обновляете строки 50,000 в таблице, триггер и запрос в нем вызываются 50,000 раз. Внешние ключи работают лучше, но они также могут запаздывать (и вы ничего не можете сделать с базовыми запросами)

В этом случае лучше поместить результаты, которые вы хотите обновить, во временную таблицу, ввести MERGE, проверить целостность до и после и применить бизнес-правила. Один запрос, обрабатывающий 50,000 строк, работает быстрее, чем цикл из 50,000 запросов, обрабатывающих одну строку.

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

В Oracle в любом случае ограничения FOREING KEY работают лучше, чем у тигров, реализующих ту же функциональность.

PRIMARY KEYS, скорее всего, улучшит производительность, поскольку первичный ключ подразумевает создание UNIQUE INDEX в ограниченном поле, и этот индекс может эффективно использоваться в запросах. UNIQUE INDEX также является естественным и наиболее эффективным способом обеспечения уникальности.

Но, конечно, как и любой индекс, замедляется INSERTS и те UPDATES и DELETES, чье WHERE условие не является селективным.

I. е. если вам нужно UPDATE или DELETE 1 строка 2,000,000, то индекс ваш друг; если вам нужно UPDATE или DELETE 1,500,000 строк по 2,000,000, индекс - ваш враг. Это вопрос компромисса.

Вы также можете увидеть мой ответ здесь .

Answer 2

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

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

Побочным эффектом является то, что часто приложения не так хорошо проверяют сами ограничения, что приводит к большому количеству мусорных данных в базе данных, что на самом деле делает более трудным для обратного инжиниринга, как FK ограничения не применяются;)

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

Answer 3

Я бы сказал, что жертвовать целостностью данных ради безопасности из-за неясности - плохая сделка.

Answer 4

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

Answer 5

(я = MSSQL)

Медленное удаление строки из большой таблицы с большим количеством FK.

Наше приложение никогда не было отказано в удалении из-за нарушения ограничения FK для этой таблицы

Я подумал о том, чтобы сбросить FK для улучшения производительности.

Слишком курица, чтобы на самом деле это сделать хотя: (

PS Мы будем хранить FK в системах DEV / TEST

Answer 6

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

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

Возможно, именно поэтому они нуждаются в вас.

Answer 7

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

Ваш друг объяснил, почему они придерживались этого мнения?