У нас есть несколько таблиц в базе данных, которые имеют двух отдельных владельцев. Оба владельца определяют идентичные ограничения первичного ключа для таблицы. Это меня озадачило. Зачем столу иметь несколько владельцев? И почему каждый владелец определяет отдельные, но идентичные первичные ключи?
Вы не можете определить два PRIMARY KEY на одной таблице в Oracle. Вы можете определить одну PRIMARY KEY и одну UNIQUE клавишу в одном наборе столбцов. Я не вижу смысла в таком дизайне.
Эти ребята создали довольно хорошо продуманную базу данных с большим количеством первичных ключей. Но они не очень использовали индексы. Когда они использовали индексы, они имели тенденцию создавать один большой индекс вместо множества различных индексов. От этого можно добиться некоторого прироста производительности?
В Oracle индекс не может использоваться для RANGE SCANS для чего-то, что не является крайним левым префиксом этого индекса.
Составной индекс для (col1, col2, col3) нельзя использовать для простого RANGE SCAN для col2 в одиночку или col3 в одиночку.
Мы также избежали ограничений внешнего ключа, таких как чума. Не уверен, почему мы сделали бы это. Есть ли причина избегать их в Oracle? Я вижу много причин, чтобы использовать их для обеспечения целостности данных между таблицами, и мы просто не используем их. Я предполагаю, что есть веская причина, и я просто не причастен к этому.
Если вы выполняете все взаимодействия с базой данных с помощью набора четко определенных процедур, оператор MERGE может дать гораздо лучшую производительность, чем FOREIGN KEY с ON DELETE CASCADE. Вы должны быть очень осторожны и привыкнуть к этой парадигме программирования.
Наконец, есть ли веская причина избегать использования триггеров (кроме очевидной ошибки, которая заключается в падении производительности)? Похоже, мы тоже этим не пользуемся.
Лично я вообще не использую триггеры. Не каждое бизнес-правило может быть выражено в виде каскадных вставок или обновлений, и любая двухпроходная операция DML приведет к изменению таблиц. Если все взаимодействие с базой данных осуществляется с помощью хранимых процедур (или пакетов), триггеры становятся бесполезными.
Использование триггеров означает на самом деле использование SQL операторов внутри CURSOR циклов, что каждый SQL чичако считает плохим.
Вы не хотите, чтобы вас видели курсорами вместо операций на основе множеств, не так ли?
FOREIGN KEY не так плохи, как триггеры (если вы не определяете CASCADE операций над ними), поскольку они просто не позволяют вам делать неправильные вещи за счет некоторой потери производительности.
Но когда ваша база данных станет больше, вы заметите, что правила проверки целостности гораздо сложнее, чем просто проверка того, что значения, вставляемые в одну таблицу, существуют в другой.
Вам придется проверять вновь вставленные значения по агрегатам, сложным объединениям и т. Д., И все проверки будут подразумевать наличие соответствующего значения в другой таблице, и провал этих проверок подрывает целостность вашей базы данных так же хорошо, как нарушение FOREIGN KEY s
Таким образом, окажется, что эти FOREIGN KEY все равно проверяются дважды и тройно, и нет смысла хранить правила целостности данных, разбросанные по всей базе данных, вместо того, чтобы хранить их в одном месте (хранимая процедура, которая всегда используется для обновления данных).