Страница 1 из 1
универсальный справочник и внешний ключ
Добавлено: 07 июл 2008, 10:31
mdfv
Есть обычная универсальная справочная таблица
где различные данные раскиданы по своим секциям
Код: Выделить всё
CREATE TABLE MULTISPRAV (
SEC INTEGER NOT NULL, // ПК секция
KOD INTEGER NOT NULL, // ПК код в секции
SVALUE VARCHAR(30)
);
Как можно прикрутить внешний ключ к полям таблиц использующих этот справочник(ссылка на KOD) без отдельных полей отвечающих за секцию? Т.е. чтобы секция для данного ключа была жестко забита.
Типа такого
Код: Выделить всё
add constraint FK_1
foreign key (pole1)
references MULTISPRAV(KOD,SEC=4);
add constraint FK_2
foreign key (pole2)
references MULTISPRAV(KOD,SEC=5);
Добавлено: 07 июл 2008, 11:03
Attid
внешний ключ добавляешь как обычный составной, а потом сверху вешаешь проверку что только 4
типа что-то вроде
Добавлено: 07 июл 2008, 11:47
mdfv
внешний ключ добавляешь как обычный составной
Вот только составлять его не из чего в том то и проблема.
Поле в таблице с данными одно.
Можно конечно наплодить полянок для секций на каждую полянку с данными, но это как-то некрасиво.
Добавлено: 07 июл 2008, 19:05
Attid
Код: Выделить всё
CREATE TABLE MULTISPRAV (
SEC INTEGER NOT NULL,
KOD INTEGER NOT NULL,
SVALUE VARCHAR(30)
);
ALTER TABLE MULTISPRAV ADD CONSTRAINT PK_MULTISPRAV PRIMARY KEY (SEC, KOD);
CREATE TABLE SP (
ID INTEGER NOT NULL,
FSEC INTEGER,
FKOD INTEGER,
LALALA VARCHAR(200)
);
ALTER TABLE SP ADD CONSTRAINT CHK1_SP check (FKOD=4
);
ALTER TABLE SP ADD CONSTRAINT PK_SP PRIMARY KEY (ID);
ALTER TABLE SP ADD CONSTRAINT FK_SP_1 FOREIGN KEY (FSEC, FKOD) REFERENCES MULTISPRAV (SEC, KOD);
??
Добавлено: 07 июл 2008, 19:44
mdfv
Это то понятно, но сильно некрасиво,
потому что придется на десяток полезных полей в одной таблице плодить кучу бессмысленных секций. Еще и индексы по ним пухлее.
Добавлено: 08 июл 2008, 00:12
hvlad
А всё потому, что неправильно выбран ПК в справочнике.
Добавлено: 08 июл 2008, 10:55
mdfv
hvlad писал(а):А всё потому, что неправильно выбран ПК в справочнике.
А как надо? И чем это поможет?
У меня разные варианты есть.
Есть отдельный ПК, а на код и секцию уник наложен.
Или ПК создавать из секции домноженной на 100..... + код?
И его подставлять в поле?
Этот вариант рассматривался, но существует теоретическая возможность, что уменьшенной разрядности для кода(или секции) тогда может не хватить.
Добавлено: 08 июл 2008, 13:45
hvlad
Не нужно запихивать KOD в ПК
Добавлено: 08 июл 2008, 14:00
mdfv
hvlad писал(а):Не нужно запихивать KOD в ПК
Что это даст?
Как на одну полянку в таблице с данными привязать фактически 2 поляны из справочника? Если не применять вышеописанные методы с вычисляемым отдельным ПК.
Добавлено: 08 июл 2008, 14:27
kdv
поляны
"Поляны"? Рекомендую жаргон прекратить.
И посмотреть еще раз на модель:
- обычно есть несколько справочников, со своими ПК по одиночному столбцу, суррогатному.
- каждый справочник представляет собой отдельную сущность
- если складывать несколько справочников в один, то мы получаем один и тот же ПК, только каждая запись в таком справочнике должна иметь свою конкретную "группу". Таким образом, получается, что столбец KOD
а) нужен только в справочнике
б) в деталях не нужен
в) пк по нему строить не надо
Добавлено: 08 июл 2008, 15:01
Merlin
kdv писал(а):поляны
"Поляны"? Рекомендую жаргон прекратить.
И посмотреть еще раз на модель:
- обычно есть несколько справочников, со своими ПК по одиночному столбцу, суррогатному.
- каждый справочник представляет собой отдельную сущность
- если складывать несколько справочников в один, то мы получаем один и тот же ПК, только каждая запись в таком справочнике должна иметь свою конкретную "группу". Таким образом, получается, что столбец KOD
а) нужен только в справочнике
б) в деталях не нужен
в) пк по нему строить не надо
Тут как бы есть шанец при ошибках кодирования получить "Моторное масло 5W40 инкрустированное алмазами по три карата" при наличии полной ссылочной целостности.
Добавлено: 08 июл 2008, 15:37
mdfv
kdv писал(а):Таким образом, получается, что столбец KOD
а) нужен только в справочнике
б) в деталях не нужен
в) пк по нему строить не надо
Справочник:
Рабочая таблица,
где каждое поле относится к отдельной секции справочника и берет только свой код внутри секции
Код: Выделить всё
ID POLESEC1 POLESEC2 POLESEC3
10 1 1 4
20 2 2 5
30 1 1 4
Коды разных секций между собой пересекаются.
Добавлено: 08 июл 2008, 16:31
hvlad
mdfv писал(а):Коды разных секций между собой пересекаются.
Зачем ?
Добавлено: 08 июл 2008, 16:31
kdv
гм. может еще раз, то же самое объяснить?
Или наоборот, спросить - зачем этот геморрой с несквозным кодом в пределах "секции"?
явный прокол с пониманием проектирования БД.
собственно, я не настаиваю. Хотите мучиться - мучайтесь дальше.
Добавлено: 08 июл 2008, 16:33
hvlad
Merlin писал(а):Тут как бы есть шанец при ошибках кодирования получить "Моторное масло 5W40 инкрустированное алмазами по три карата" при наличии полной ссылочной целостности.
А это прикладные ограничения, не имеющие отношения к RI.
Триггерами\процедурами\чеками вполне решаемые.
Добавлено: 08 июл 2008, 16:35
kdv
Тут как бы есть шанец при ошибках кодирования получить "Моторное масло 5W40 инкрустированное алмазами по три карата" при наличии полной ссылочной целостности.
а тогда зачем универсальный справочник? и чем поможет его разбиение на секции?
человек-то хочет чтобы одна часть значений ПК вводилась "вот сюда", а другая - "туда". и чтобы одну в другой нельзя было использовать.
А FK с разделением по значениям не делается.
Добавлено: 08 июл 2008, 16:51
mdfv
kdv писал(а):гм. может еще раз, то же самое объяснить?
Или наоборот, спросить - зачем этот геморрой с несквозным кодом в пределах "секции"?
явный прокол с пониманием проектирования БД.
собственно, я не настаиваю. Хотите мучиться - мучайтесь дальше.
Свои справочники я то нормально делаю, а данная структура не моя и периодически обновляемая извне, вот и ищу способ облегчения ситуации с минимальными затратами.
Добавлено: 08 июл 2008, 17:15
Merlin
hvlad писал(а):Merlin писал(а):Тут как бы есть шанец при ошибках кодирования получить "Моторное масло 5W40 инкрустированное алмазами по три карата" при наличии полной ссылочной целостности.
А это прикладные ограничения, не имеющие отношения к RI.
Триггерами\процедурами\чеками вполне решаемые.
Как бы это поинтеллегетней-то... Газонокосилка... гамак... И всё ради того, чтобы сначала уйти от десятка справочников, а потом от двухсегментных ПК-ФК, решающих вопрос однозначно и без плясок с бубном. Но - некрасиво, немодно, я понимаю...
Добавлено: 08 июл 2008, 17:25
Merlin
kdv писал(а):
а тогда зачем универсальный справочник?
Это ты меня спрашиваешь?
kdv писал(а):
и чем поможет его разбиение на секции?
Хранение в одной таблице сущностей с разным физическим смыслом, но с одинаковой структурой мат. модели. Бывает полезно, скажем, чтоб не думать, с какой таблицей джойниться. Но редко. Обычно таки либо строят иерархию справочников, либо сажают деревья. А тут пытаются скрестить ужа с ежом - одна таблица, но плоская, алгоритмы обслуживания которой управляются значениями некоего атрибута, входящего в ПК. Я применяю местами, но не для справочников.
kdv писал(а):
человек-то хочет чтобы одна часть значений ПК вводилась "вот сюда", а другая - "туда". и чтобы одну в другой нельзя было использовать.
А FK с разделением по значениям не делается.
Человек сегмент ФК хочет как-то сэкономить. Уже наломавши дров. Исходя из эстетических соображений.
Добавлено: 09 июл 2008, 14:55
Gera
зачем этот геморрой с несквозным кодом в пределах "секции"?
Было несколько столбцов со справочником "да"/"нет" потом один понадобилось изменить на "да"/"нет"/"50%" и код у "да" и "нет" остались теме же.
в противном случае при добавлении нового справочника коды изменятся значительно. И придется переделывать все отчеты, где есть привязка к конкретным значениям справочников. Есть печальный опыт.