использование уникальных ограничений для упрощения соединений

Question

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

Вот СЛУЧАЙ A:

/*SCHEMA*/
CREATE TABLE SCHEMA (
SCHEMA_ID    INTEGER,
CONSTRAINT sch_pk PRIMARY KEY (SCHEMA_ID)
);

/*OBJECTS*/
CREATE TABLE OBJECT (
OBJECT_ID    INTEGER,
SCHEMA_ID    INTEGER NOT NULL,
CONSTRAINT obj_pk PRIMARY KEY (OBJECT_ID),
CONSTRAINT obj_sch_uniq UNIQUE (OBJECT_ID,SCHEMA_ID),
CONSTRAINT obj_fk FOREIGN KEY (SCHEMA_ID) REFERENCES SCHEMA(SCHEMA_ID)
);

/*COLUMNS*/
CREATE TABLE COL (
COL_ID      INTEGER,
OBJECT_ID   INTEGER,
CONSTRAINT col_pk PRIMARY KEY (COL_ID),
CONSTRAINT col_obj_uniq UNIQUE (COL_ID,OBJECT_ID),
CONSTRAINT col_fk FOREIGN KEY (OBJECT_ID) REFERENCES OBJECT(OBJECT_ID)
);

Вот СЛУЧАЙ B:

/*SCHEMA*/
CREATE TABLE SCHEMA (
schema_id               INTEGER,
CONSTRAINT schema_pk PRIMARY KEY (schema_ID),
);

/*OBJECTS*/
CREATE TABLE OBJECT (
object_id               INTEGER,
schema_id               INTEGER,
CONSTRAINT object_pk PRIMARY KEY (object_id,schema_id),
CONSTRAINT object_schema_fk FOREIGN KEY (schema_id) REFERENCES SCHEMA (schema_id)
);

/*COLUMNS*/
CREATE TABLE COL (
column_id               INTEGER,
object_id               INTEGER,
schema_id               INTEGER,
CONSTRAINT column_pk PRIMARY KEY (column_id,object_id,schema_id),
CONSTRAINT column_object_fk FOREIGN KEY (object_id,schema_id) REFERENCES OBJECT (object_id,schema_id)
);

Общий запрос, который будет выполняться для этих наборов таблиц, выглядит следующим образом: СЛУЧАЙ A

SELECT *
FROM METADATA_CONTROL.COL
INNER JOIN METADATA_CONTROL.OBJECT ON METADATA_CONTROL.COL.OBJECT_ID = METADATA_CONTROL.OBJECT.OBJECT_ID
WHERE OBJECT.SCHEMA_ID = 101;

ДЕЛО B

SELECT *
FROM METADATA_CONTROL.COL
WHERE SCHEMA_ID = 101;

Как видно, CASE A требует соединений, а CASE B - нет. Мои вопросы:

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

Я слаб в понимании прироста производительности / штрафов различных структур реляционных таблиц. Это на Oracle 12c.

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

Спасибо!

Answer 1

Это не эквивалентные модели.

Рассмотрим следующие 2 строки в таблице OBJECT:

OBJECT_ID    SCHEMA_ID
1            1
1            2

Вы можете вставить обе строки в CASE B. Вы не можете вставить обе строки в CASE A. Первичные ключи все-таки уникальны, поэтому PRIMARY_KEY (OBJECT_ID) означает, что OBJECT_ID уникален в таблице OBJECT.

Теперь, если вы хотите разрешить приложению применять ограничение "OBJECT_ID is unique", тогда вы могли бы использовать CASE B для хранения данных, соответствующих требованиям CASE A. Вы, вероятно, не должны, но вы могли бы. То есть все, что вы можете поместить в базу данных в CASE A, вы можете поместить в базу данных в CASE B. Обратное неверно.

Так что выбирайте между делом А и В в первую очередь исходя из правильности.

В случае A - уникальное ограничение является избыточным - снова при просмотре таблицы OBJECT OBJECT_ID уже уникален. Таким образом, вам не нужно это ограничение на вашем столе.

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

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

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