-
Привет Мастера :) Есть необходимость создания рекурсивного внешнего ключи на саму запись.
CREATE TABLE LCA_ACCPOINTS (
CODE D_APCODES NOT NULL /* D_APCODES = VARCHAR(10) */,
CONSUMER D_CONCODES NOT NULL /* D_CONCODES = VARCHAR(8) */,
SUPPLIER D_APCODES NOT NULL /* D_APCODES = VARCHAR(10) */,
WORKHOUR D_INT NOT NULL /* D_INT = INTEGER */,
WORKDAY D_INT NOT NULL /* D_INT = INTEGER */,
OPENDATE D_DATE NOT NULL /* D_DATE = DATE */,
CLOSEDATE D_DATE /* D_DATE = DATE */,
TSTATION D_CTLCODES NOT NULL /* D_CTLCODES = INTEGER */,
STREET D_CTLCODES NOT NULL /* D_CTLCODES = INTEGER */,
HOUSE D_HSAPS NOT NULL /* D_HSAPS = VARCHAR(4) */,
APART D_HSAPS /* D_HSAPS = VARCHAR(4) */,
DESCRIPTION D_DESCRIPTIONS /* D_DESCRIPTIONS = VARCHAR(255) */
);
ALTER TABLE LCA_ACCPOINTS ADD CONSTRAINT PK_LCA_ACCPOINTS_CODE PRIMARY KEY (CODE);
ALTER TABLE LCA_ACCPOINTS ADD CONSTRAINT FK_LCA_ACCPOINTS_CONSUMER FOREIGN KEY (CONSUMER) REFERENCES LCA_CONSUMERS (CODE) ON DELETE CASCADE ON UPDATE CASCADE;
ALTER TABLE LCA_ACCPOINTS ADD CONSTRAINT FK_LCA_ACCPOINTS_STREET FOREIGN KEY (STREET) REFERENCES CTL_STREETS (CODE) ON DELETE CASCADE ON UPDATE CASCADE;
ALTER TABLE LCA_ACCPOINTS ADD CONSTRAINT FK_LCA_ACCPOINTS_SUPPLIER FOREIGN KEY (SUPPLIER) REFERENCES LCA_ACCPOINTS (CODE) ON DELETE CASCADE ON UPDATE CASCADE;
ALTER TABLE LCA_ACCPOINTS ADD CONSTRAINT FK_LCA_ACCPOINTS_TSTATION FOREIGN KEY (TSTATION) REFERENCES ENC_TSTATIONS (CODE) ON DELETE CASCADE ON UPDATE CASCADE;
Вопрос: Чем это чревато и на какие подводные камни я могу натолкнуться?
-
В dBase нет внешних ключей.
-
> [0] Sirus (17.12.08 08:07) > Вопрос: Чем это чревато и на какие подводные камни я могу натолкнуться? Ответ: При кривой реализации можно натолкнуться на все что угодно. При нормальной реализации - это нормальная "деревянная" структура.
ЗЫ: Я конечно рискую опять спровоцировать спор про суррогатные ключи, но все таки - почему ПК - VARCHAR(10)?
-
> Вопрос: Чем это чревато и на какие подводные камни я могу > натолкнуться?
Поскольку on delete cascade стоит, то при случайном удалении рутового элемента...
-
> Вопрос: Чем это чревато и на какие подводные камни я могу > натолкнуться?
Да, собственно, вполне нормальная ситуация для парентовых деревьев. Все так и делают. Вот только каскадное удаление, действительно, стремновато . . .
-
> Все так и делают.
весьма смелое утверждение
-
> весьма смелое утверждение
А как ты иначе иерархическую структуру построишь с проверкой ссылочной целостности на уровне СУБД?
-
> Ega23 © (17.12.08 13:23) [6]
напимер, на 2 таблицах
-
> Ega23 © (17.12.08 13:23) [6] > А как ты иначе иерархическую структуру построишь с проверкой > ссылочной целостности на уровне СУБД?
где-то мне на эту тему интересная статеюшка попадалась... но ведь не найду.
-
> где-то мне на эту тему интересная статеюшка попадалась
емнип, на королевстве
-
> напимер, на 2 таблицах
Вопрос: а зачем плодить лишние сущности?
> где-то мне на эту тему интересная статеюшка попадалась.. > . но ведь не найду.
Я их много читал в своё время. И варианты разные пробовал. Остановился на варианте с одной таблицей с id и parid и ключом на саму себя. Единственное, Root должен быть один (но за этим тоже СУБД следит).
-
>Sirus (17.12.08 08:07) >Вопрос: Чем это чревато и на какие подводные камни я могу натолкнуться? искать по "pig's ear"
-
> Вопрос: а зачем плодить лишние сущности?
а это уже от задачи зависит не все задачи и способы их решения одинаково хороши во всех случаях
-
> весьма смелое утверждение
Ну не делают те, кто вообще ограничениями не пользуются. Например наша контора :)
-
> Ну не делают те, кто вообще ограничениями не пользуются
снова обобщение на основании частного случая я пользуюсь ограничениями, но при этом иерархию делаю и 2 таблицами, и одной - зависит от задачи
-
> ANB (17.12.08 17:56) [13]
героический армянскй комсомол :)
|