|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Приветствую. Есть родительская таблица contragents id serial PK; title_name character varying; Есть дочерние таблички: persons id serial PK; -- унаследовано от contragents title_name character varying; -- унаследовано от contragents sex boolean; organizations id serial PK; -- унаследовано от contragents title_name character varying; -- унаследовано от contragents activity_type_id integer; Есть независимая таблица buildings id serial PK; owner_id integer; Мне нужно организовать Foreign Key одним из способов: 1. buildings.owner_id в идеале связать с contragents.id; 2. buildings.owner_id связать с organization.id или c persons.id Первый способ идеальный. Но при добавлении строки в persons запись в contragents еще не появилась, соответственно возникает проблема - ключ отсутствует и транзакция откатывается. Второй способ - не знаю как это записывается (возможно ли это вообще?). Варианты - перепроектировать дизайн базы данных не предлагать. Заранее благодарен за любую конструктивную помощь. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 19:37 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Elfix, Что значит "унаследована"? Если: Код: sql 1.
то при появлении записи в `persons` она должна быть и в `contragents`. Если не так, то приведите DDL. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 20:18 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
vyegorovElfix, Что значит "унаследована"? Если: Код: sql 1.
Это и значит.vyegorovто при появлении записи в `persons` она должна быть и в `contragents`. Это если убрать любые вторичные ключи. Если же их добавить, то возникает ошибка = ключ 1 не найден. Т. е. он генерируется, вставляется в дочернюю таблицу, но затем проиходит ошибка и вся транзакция откатывается. Об этом много написано на форумах, я склонен думать, что это баг. Поэтому ищу способ сделать FK к двум таблицам-исходникам, игнорировав родительскую таблицу. Как это сделать? И возможно ли это? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 21:16 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Ну вот листинги: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54.
При добавлении записи в persons ошибки не возникает. В contragents запись появляется. Ключ равен 1. В persons ключ тоже равен 1. Далее при добавлении записи в таблицу buildings с owner_id = 1 возникает ошибка: INSERT или UPDATE в таблице "buildings" нарушает ограничение внешнего ключа "owner_id_fk". DETAIL: Ключ (owner_id)=(1) отсутствует в таблице "contragents". ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 21:30 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Elfix, Ну да, всё так и должно быть (тупанул): Код: sql 1.
Elfixперепроектировать дизайн базы данных не предлагать В данном случае желаемого эффекта можно достичь, если сделать обычные таблицы, без наследования. Но перепроектировать надо будет. Я бы не рекомендовал с наследованием связываться вообще, больше неожиданностей, чем удобства. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 22:14 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
vyegorov, а есть ли возможность сделать foreign key к двум таблицам-дочерям? Уверен, что как-то можно, но никак не удается. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 22:56 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Elfixvyegorov, а есть ли возможность сделать foreign key к двум таблицам-дочерям? Уверен , что как-то можно, но никак не удается. зря. наследование в пж -- это довольно мертворожденная штука, так и не нашедшая достаточно сумасшедших поклонников, чтобы сделать её осмысленной. применяется обычно только для партицирования. где--то маргинально ее пользуют якобы по изначальному назначению, но не широко. я как--то давно пользовал для чего--то такого. но удобств особых не наблюл. как сделать "фк" делаете "центр звезды" -- отдельно стоящую (обычную, а не наследуемую) таблицу из всех id--иков гирлянды наследования (обвязав те триггерами на пополнение / удаление "центра"). и вот к такому "центру" вяжетесь своими фк. много хенджоба и куча неудобств, в т.ч. не с разбега отладите каскады, думаю. (сами фк так не пытался строить, но поддерживать уникальность id на всей гирлянде удается, если в триггерах не наврёте) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 23:20 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
qwwqнаследование в пж -- это довольно мертворожденная штука, так и не нашедшая достаточно сумасшедших поклонников, чтобы сделать её осмысленной.Еще бы. FK сделать нельзя - и вся логика использования этого чудесного механизма сходит на нет. В остальном довольно удобно. В случае если поля таблиц будут расширяться, переписывать массу тригеров и проверок будет достаточно сложно. Наследование же - штука прекрасная, но из-за вот таких нелогичных поведений СУБД пользоваться им становится невозможно... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2016, 02:26 |
|
Foreign Key к двум таблицам или к родительской таблице
|
|||
---|---|---|---|
#18+
Elfixqwwqнаследование в пж -- это довольно мертворожденная штука, так и не нашедшая достаточно сумасшедших поклонников, чтобы сделать её осмысленной.Еще бы. FK сделать нельзя - и вся логика использования этого чудесного механизма сходит на нет.тут грустно. можно сделать материальный самопальный объект "центр" с уникью над ним но нельзя сделать виртуальный объект "центр", с уникъю (абстракцией) над несколькими частичными уникъю -- СУБД таких удобств не предоставляет ну и нельзя сделать ФК на такой не предоставленный "уникъю" над множеством однотипных индексов. тут смелых студентов от стоунбрейкера не бегало. ElfixВ остальном довольно удобно. В случае если поля таблиц будут расширяться, переписывать массу тригеров и проверок будет достаточно сложно. Наследование же - штука прекрасная, но из-за вот таких нелогичных поведений СУБД пользоваться им становится невозможно... про массу триггеров для поддержания только поля (полей) ключа, и , м.б., партицирующего --- умозаключение неверное. в центре кроме ключа ничего быть не должно. он обслуживает материализованное уникъю для иерархии типов сущностей. только при изменении самого ключа -- будут траблы. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2016, 10:33 |
|
|
start [/forum/topic.php?fid=53&fpage=80&tid=1996782]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
62ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 318ms |
total: | 474ms |
0 / 0 |