Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.144.189.177] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
firebird 3.0, IBExpert
имеется несколько таблиц с идентичной структурой: CREATE TABLE TABLE_X ( ID DBD$ID /* DBD$ID = BIGINT NOT NULL */, ENTRY VARCHAR(32) NOT NULL ); ALTER TABLE TABLE_X ADD CONSTRAINT UNQ_TABLE_X UNIQUE (ENTRY); и несколько таблиц (структура разная, показана общая часть): CREATE TABLE AGRS_X( ID DBD$ID /* DBD$ID = BIGINT NOT NULL */, FIELD_1 DBD$REFERENCE /* DBD$REFERENCE = BIGINT NOT NULL */, ... FIELD_N DBD$REFERENCE /* DBD$REFERENCE = BIGINT NOT NULL */ ... ); ALTER TABLE AGRS_X ADD CONSTRAINT FK_AGRS_X_FIELD_1 FOREIGN KEY (FIELD_1) REFERENCES TABLE_1 (ID); ... ALTER TABLE AGRS_X ADD CONSTRAINT FK_AGRS_X_FIELD_N FOREIGN KEY (FIELD_N) REFERENCES TABLE_N (ID); наборы таблиц (TABLE_X) на которые ссылаются AGR_X разные и не пересекаются т.к. таблиц(TABLE_X) много и их структура одинакова, хотелось бы объединить их в одну что-то вроде: CREATE TABLE TABLE_X ( ID DBD$ID /* DBD$ID = BIGINT NOT NULL */, CODE SMALLINT NOT NULL, ENTRY VARCHAR(32) NOT NULL ); ALTER TABLE TABLE_X ADD CONSTRAINT UNQ_TABLE_X UNIQUE (CODE, ENTRY); стоит ли так делать? и как быть с foreign key? структуру AGRS менять не желательно |
Сообщ.
#2
,
|
|
|
Сделать так можно, но есть ли гарантия что все TABLE_X.ID будут уникальными? у тебя же все равно должен быть PK по колонке ID (если нельзя менять таблицу AGRS). Либо создавать ПК по паре ID, CODE и FK настраивать на эту пару.
Но с точки зрения здравого смысла стоит все-таки разнородные сущности хранить в разных таблицах. Иначе на вставках могут посыпаться конкуренции за один и тот же объект при поиске родительских записей (на больших объемах) |