Производительность ключей Fk / Pk БД

Question

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

Это означает, что мы не будем вставлять запись, скажем, в таблицу USERS, в ту же транзакцию, также USERS_PETS и USERS_PARENTS (и еще 10) с несколькими строками на основе одного и того же уникального идентификатора из основной таблицы. *

Поскольку приложение, использующее эту БД, постоянно вставляет новые записи и обновляет существующие, связь между этими таблицами сохраняется только на уровне приложения (т. Е. Логическая ERD, а не обработка с помощью замедлений FK / PK).

Вопросы:

1. Правильно ли предположить, что с точки зрения чистой производительности это лучший подход?
2. Есть ли способ установить эти ключи (чтобы БД была более информативной), не влияя на производительность?

Answer 1

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

Answer 2

Вы основываете целостность данных на надежде.Надежда плохо масштабируется.

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

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

Answer 3

1. Нет, по той же причине мы используем ремни безопасности в автомобилях, даже когда мы спешим. Разница ничтожна и совершенно не стоит.
2. Некоторые конкретные поставщики БД могут предлагать способ объявления ограничений, не применяя их. Например, в Oracle вы можете указать состояние ограничения целостности как DISABLE NOVALIDATE.