Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Всем здравствуйте. Точно знаю, что подобная тема здесь уже была, встречал, но вот найти никак не могу :( Есть таблица, в ней необходимо сделать внешний ключ, который может ссылаться на одну из двух таблиц, как это лучше реализовать: 1. Сделать PK в каждой из двух таблиц сквозной, т.е. поле IDENTITY с непересекающимися значениями. Соответственно, берем значение внешнего ключа в связанной таблице и ищем поочередно в каждой из двух родительских таблиц. 2. Сделать в связанной таблице два поля - внешние ключи на каждую из таблиц. Одно из полей всегда NULL. Проверяем, какое из полей не NULL и обращаемся к соответствующей родительской таблице. Расширения не будет, т.е. родительских таблиц всего две. Подскажите, пожалуйста, как лучше сделать? Можно ссылкой на подобную тему. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 11:10 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
KezyaВсем здравствуйте. Точно знаю, что подобная тема здесь уже была, встречал, но вот найти никак не могу :( эта тема обычно поднимается, когда речь заходит о физиках-юриках можно искать по топикам Физические лица, Юридические лица ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 11:40 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Спасибо ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 11:40 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Есть таблица, в ней необходимо сделать внешний ключ, который может ссылаться на одну из двух таблиц, как это лучше реализовать: Применительно к физическим-юридическим лицам и т.д. лучший вариант - хранить данные не в двух разных таблицах, а в одной. Например CUSTOMER. При желании к этой таблице можно создать подчиненную, где хранить дополнительные атрибуты юридических лиц. Все другие варианты - хуже. -- Шумов В. http://www.acdplus.ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 14:01 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
У меня не физ. и юр. лица :) Сущности разные, схожих атрибутов у них нет. Сделал одно поле - внешний ключ и поле-признак, значение в котором и будет означать из какой сущности взят экземпляр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 16:47 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
KezyaУ меня не физ. и юр. лица :) Сущности разные, схожих атрибутов у них нет. Сделал одно поле - внешний ключ и поле-признак, значение в котором и будет означать из какой сущности взят экземпляр. можно сделать одну общую "сквозную" "опорную" "единую" таблицу ключей (EntryID EntryDate etc.) для разных сущностей - по ним и определять откуда данные о сущности (таблиц таким образом может быть и не две... и не пять...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 19:09 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Kezya На мой взгляд, неправильно сделали. Если это абсолютно разные сущности, то лучше в главной таблице сделать два поля. Зачем экономить-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 21:32 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Вот еще. С таким подходом Вы не напишите нм одного нормального запроса ни на одном диалекте SQL. По всей видимости Вы еще не совсем освоились в реляционных БД и мыслите навигационным способом доступа к данным :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2005, 21:43 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
В главной таблице у этих разных сущностей есть общее поле - количество. Cat2 По всей видимости Вы еще не совсем освоились в реляционных БД это верно :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 06:32 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
VladShПрименительно к физическим-юридическим лицам и т.д. лучший вариант - хранить данные не в двух разных таблицах, а в одной. Меня всегда умиляли слова "лучше так" при абсолютно неизвестной постановке задачи (то есть - как именно будет использоваться это "так"). VladShНапример CUSTOMER. Если CUSTOMER - то действительно например. Но подброшу другой например, из моей практики: хранятся данные о самой фирме и ее филиалах (сотрудники и оргструктура), контрагентах (те самые customer), банках (которые само собой юрики и которые могут быть контрагентами) ключевых сотрудниках контрагентов-юриков и банков (грубо говоря, контакты), расчетных счетах, которые физик или юрик может иметь в банке. Признаться, с огромным интересом изучил бы хорошую реализацию, в которой все это свалено в одну таблицу. Например, хранение данных о физике, который является контрагентом, одновременно является сотрудником банка-контагента и имеет счет в своем банке :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 12:19 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
KezyaСделал одно поле - внешний ключ и поле-признак, значение в котором и будет означать из какой сущности взят экземпляр. Присоединюсь к предыдущим ораторам. Это решение во-первых наиболее неудобно в использовании, а во-вторых, наиболее ненадежно, чревато проблемами в сопровождении (разрешите не расшифровывать почему, если угодно - просто точка зрения). Нормальные решения уже были названы - это либо "сквозная" таблица, объединяющая две сущности, либо то, что в Oracle Designer-е называется "дугой" - два поля, два foreign key и check constraint вида (a is null and b is not null or a is not null and b is null). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 12:24 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Да, прошелся поиском по форуму, нашел кучу поднобных тем. Знал ведь, что они есть :) Решение с битовым полем-"переключателем" действительно не очень удачное, сделал Softwarer ...то, что в Oracle Designer-е называется "дугой" - два поля, два foreign key и check constraint вида (a is null and b is not null or a is not null and b is null). Еще раз большое всем спасибо за советы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 18:44 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Хм, возникла интересная ситуация: сначала в таблице внешний ключ ссылался всего лишь на одну таблицу и этот внешний ключ являлся составной частью первичного ключа. Я не стал делать суррогатный ключ, а сделал составной. Первичный ключ для таблицы состоял из трех внешних ключей, теперь же добавляется четвертый, но так, что два внешних ключа являются "взаимоисключающими", т.е. один из них всегда(!) NULL. Возможно ли создание такого PK, состоящего из 4-х полей таблицы, причем одно из них всегда будет NULL? Я конечно попробую все же создать, но насколько хорошо будет такое решение (если получится)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 19:45 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Поле с возможностью NULL значения не может быть частью PK. Очень удобно ссылочная целостность реализовывалась, как в таком случае ее поддерживать - триггерами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 19:55 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
KezyaПоле с возможностью NULL значения не может быть частью PK. Очень удобно ссылочная целостность реализовывалась, как в таком случае ее поддерживать - триггерами? Лучше сделать PK все таки суррогатным ключом, а на поля сделать UNIQUE CONSTRAINT/INDEX (если конечно Оракл позволяет нормально делать UNIQUE на NULL-поля). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 21:59 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
Надо в сущности , на которую нужно ссылаться, выделить общего предка, применив отношение подкатегории. И на него (общего предка) тогда и ссылаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2005, 22:22 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
KezyaПервичный ключ для таблицы состоял из трех внешних ключей, теперь же добавляется четвертый, "А зачем нам кузнец?" (c) Почти всегда лучше обойтись без подобных первичных ключей. Для адресации нужной записи в таблице составной ключ из четырех полей, мягко говоря, неудобен. А если адресовать записи не требуется - зачем первичный ключ? Делайте просто уникальный по требуемому набору полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 01:29 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
ASCRUS(если конечно Оракл позволяет нормально делать UNIQUE на NULL-поля). Позволяет. Даже позволяет создать foreign key, ссылающийся на такой unique constraint. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 01:30 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
У меня не Oracle, а MS SQL Server. Сделаю, наверное, суррогатный ключ. "Опорную" таблицу делать имеет смысл если таблиц более 2-х, мне же хватит и одной :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 05:48 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
softwarer Если CUSTOMER - то действительно например. Но подброшу другой например, из моей практики: хранятся данные о самой фирме и ее филиалах (сотрудники и оргструктура), контрагентах (те самые customer), банках (которые само собой юрики и которые могут быть контрагентами) ключевых сотрудниках контрагентов-юриков и банков (грубо говоря, контакты), расчетных счетах, которые физик или юрик может иметь в банке. Правильно, давайте всё в кучу. Делить клиентов на "контрагентов" и "неконтрагентов" -- дальновидное и технически грамотное решение :) Если серьёзно -- "контрагенты", "расчётные счета" и т.п. это всё преходяще и должно описываться отдельными сущностями. Деление на "физиков" и "юриков" вечно и неизменно, и два поля, одно из которых не null, и битовый флаг -- решения равнозначные. Единственное неудобство -- во втором случае нельзя сделать FK, но я считаю FK злом :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 13:49 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
hardsignДеление на "физиков" и "юриков" вечно и неизменно :) а физиков на физиков с ИНН и без? а физиков на резидентов и не резидентов "вечных и неизменных" делений несть числа - это показывает практика у кого-то она шире... у кого-то уже... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 14:08 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
sgdsfgsfgsfgsfgsfgа физиков на физиков с ИНН и без? а физиков на резидентов и не резидентов "вечных и неизменных" делений несть числа - это показывает практика Да ну? Физик без ИНН может получить ИНН. Физик-резидент может эмигрировать (или наоборот -- нерезидент может получить гражданство). Юрик физиком не станет никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 14:45 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
hardsign sgdsfgsfgsfgsfgsfgа физиков на физиков с ИНН и без? а физиков на резидентов и не резидентов "вечных и неизменных" делений несть числа - это показывает практика Да ну? Физик без ИНН может получить ИНН. Физик-резидент может эмигрировать (или наоборот -- нерезидент может получить гражданство). Юрик физиком не станет никогда. меньше боевого задора - я в вам про Кузьму вы мне про Ярему... а вдруг станет? что будете делать - харакири? по категории физики юрики субъектов хозяйственной деятельности различает законодатель ИМХО - а ну как он перестанет различать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 15:18 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
rtwertwertwertwertwertwertwet а вдруг станет? что будете делать - харакири? Да бог с ним. Возражение гораздо проще - у меня упомянута, например, таблица банков, которая ссылается на юриков (банк физиком быть не может). Еще там упомянуты сотрудники, которые вряд ли могут быть кем-то кроме физиков. Итого, если валить физиков с юриками в одну таблицу - начинаются пляски с целостностью. Правда, уже было задекларировано "зло", на что трудно возразить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 16:06 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
пообсуждаем?... ) Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 17:58 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
gardenmanпообсуждаем?... Как-то бессмысленно обсуждать, не имея постановки задачи. Флейм получится. Из общих соображений - меня несколько смущает то, что people и organization обязаны быть customer-ами, ну и то, что я назвал "пляска с целостностью" - по понятным причинам аж в таблицу документов залезло техническое поле org_type. Наконец, в данной схеме чрезвычайно неудобен путь от "документа" к "общим атрибутам клиентов". Итого - во-первых, я бы скорее протянул foreign key в обратную сторону (от customer к people/organization). Во-вторых, в doc ссылался бы на customer_id. В-третьих, убрал бы поле типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 18:54 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
автор, в данной схеме чрезвычайно неудобен путь от "документа" к "общим атрибутам клиентов". Как раз наоборот. Все очень-очень просто. За общими отрибутами не надо ходить в People или Org - можно напрямую приджойнить customer. автор Итого - во-первых, я бы скорее протянул foreign key в обратную сторону (от customer к people/organization). Во-вторых, в doc ссылался бы на customer_id. В-третьих, убрал бы поле типа. Приведите пример пожалуйста. Для наглядности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2005, 19:15 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
softwarer Из общих соображений - меня несколько смущает то, что people и organization обязаны быть customer-ами, Можно несколько переформулировать определение кастомера: это любой субъект, с которым приходится иметь дело. Тогда не жалко валить туда и физиков, и юриков. Контрагентом субъект становится в тот момент, когда с ним заключается соответствующий договор. Тогда, чтобы определить контрагента, надо идти от договора, а не от справочника клиентов. Вполне жизнеспособный подход. softwarer ну и то, что я назвал "пляска с целостностью" - по понятным причинам аж в таблицу документов залезло техническое поле org_type. Тоже жизнеспособный подход -- составной первичный ключ, часть которого является внешним ключом. Он тоже может кому-то не нравиться (как мне, например, не нравятся физические FK :)), но, тем не менее, это работает и в OLTP иногда очень удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 12:05 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
2 gardenman Структурно ключом все-таки должен быть customer_id Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Во-вторых в косметических целях поменял бы название customer на party (действующее лицо). Клиент - это скорее роль. У одного действующего лица ролей может быть много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:15 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
авторСтруктурно ключом все-таки должен быть customer_id Сможете обосновать? автор customer на party Я подумаю над этим. Однако привычка - знаете ли большое дело. По мне так абсолютно никакой разницы первичный ключ составной или из одного поля. Для меня существенно другое - Если клиент существует, то для него обязательно должна быть запись в таблице Customer. И опять же Customer должен быть упомянут только один раз и должен иметь совершенно определенный тип. Единственная проблема которую я тут вижу - можно удалить строку из People а в Customer она останется. Поэтому без триггеров такая схема до конца не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:35 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
hardsignМожно несколько переформулировать определение кастомера: это любой субъект, с которым приходится иметь дело. "Субъект" - согласен, будет нормальная сущность. А вот кастомер - не нравится; захочется внести туда собственных сотрудников и выяснится, что приходится обозвать их кастомерами :) Тогда, чтобы определить контрагента, надо идти от договора, а не от справочника клиентов. Вполне жизнеспособный подход. Идти от договора - правильно. В данном случае мне не нравится другое: для того, чтобы получить "общие атрибуты клиента", например категорию, нужно писать запрос типа Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Получается так, что наиболее нужная информация засунута максимально далеко. Тоже жизнеспособный подход -- составной первичный ключ, часть которого является внешним ключом. Жизнеспособный и иногда очень удобный. Я сам им пользуюсь. Но в данном случае не вижу в его применении никаких преимуществ, только если из принципа показать, что можно ввести признак типа и при этом сделать целостность на внешних ключах. Как неформальный признак - imho такой подход оправдан, когда не нужно вносить дополнительных технических полей, то есть когда поля составного ключа по своему смыслу должны присутствовать в каждой из таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:37 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
автор"Субъект" - согласен, будет нормальная сущность. А вот кастомер - не нравится; захочется внести туда собственных сотрудников и выяснится, что приходится обозвать их кастомерами :) А что, собственный сотрудник разве не может быть кастомером? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:43 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
2 softwarer Таблицу Doc я привел в пример лишь для того, чтобы показать как можно накрутить ссылочную целостность на такую схему. Например, если потебуется хранить организацию и ее сотрудников и обеспечить связь между ними. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:48 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
gardenmanА что, собственный сотрудник разве не может быть кастомером? Может. Но совершенно не обязан им быть. Поэтому внешние ключи, например, кастомер -> физик и сотрудник -> физик вполне удобны, а вот notnull-овский физик -> кастомер - искусственен, не отражает реальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 13:56 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
gardenman авторСтруктурно ключом все-таки должен быть customer_id Сможете обосновать? Общеэстетические соображения: Party_idParty_type1'O'1'P' вызывает вопрос так '1' у нас человек или организация? Ответ ясен O1 это одно а P1- другое, но все же.... во-вторых включение смыслового атрибута в суррогатный ключ в общем случае не лучшая практика. Производительность, кодирование: короткие ключи безусловно лучше. А главное, цель (контроль целостности Party - Organization xor Person) достигается и при коротком ключе, зачем усложнять. Наконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 14:01 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
ModelRНаконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK. Хм. Возможно тупой вопрос, но - а в чем разница? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 14:07 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
2 ModelR взвесил, что вы написали. действительно: Код: plaintext 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. Я б на такую схему вообще поставил - "рекомендовано к использованию" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 14:16 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
softwarer ModelRНаконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK. Хм. Возможно тупой вопрос, но - а в чем разница?Нет тупых вопросов, есть тупые ответы. Надеюсь не этот. Имеется ввиду, что в действующей системе многие запросы, функции и другой код как правило составлены с учетом ПК. Переделываем ПК - переделывает джойны по ПК и еще массу кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 16:05 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
[quot softwarer]В данном случае мне не нравится другое: для того, чтобы получить "общие атрибуты клиента", например категорию, нужно писать запрос типа Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. М-да, видать я недостаточно внимательно читал исходное сообщение. Конечно, маразм. Мне казалось, что тот факт, что ключ "субъекта" является уникальным (т.е. грубо говоря, и для физиков и для юриков берётся из одной последовательности), очевиден для всех и обсуждению не подлежит. А если взять из договора subject_id, то он будет ключом в subject, а также в одной из таблиц "физик" и "юрик"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2005, 17:16 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
ModelRИмеется ввиду, что в действующей системе многие запросы, функции и другой код как правило составлены с учетом ПК. Переделываем ПК - переделывает джойны по ПК и еще массу кода. Cовершенно не обязательно. Если "старый ПК перестает быть уникальным" - тогда да, геморрой. Если же идет именно реорганизация, типа "старый ПК сделали просто уникальным, а ПК объявили что-то еще" - проблемы будут только у изрядно кривых приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 16:37 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
hardsignМне казалось, что тот факт, что ключ "субъекта" является уникальным (т.е. грубо говоря, и для физиков и для юриков берётся из одной последовательности), очевиден для всех и обсуждению не подлежит. А если взять из договора subject_id, то он будет ключом в subject, а также в одной из таблиц "физик" и "юрик"... Виноват, не подумал об этом. Похоже, просто сказалась привычка к другому типу структур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 16:44 |
|
||
|
Внешний ключ на две таблицы (+)
|
|||
|---|---|---|---|
|
#18+
softwarerЕсли "старый ПК перестает быть уникальным" - тогда да, геморрой. Если же идет именно реорганизация, типа "старый ПК сделали просто уникальным, а ПК объявили что-то еще" - проблемы будут только у изрядно кривых приложений.Согласен, смысл моего поста как раз в этом и был - сохранить уникальность как она есть. Но я под "реорганизацией" понимал именно то, что будет разрешено Party_id; Party_type 1; 'O' 1; 'P' "старый ПК (K1) сделали просто уникальным, а ПК объявили что-то еще (K2)" - мне не пришло в голову, я бы просто создал новый UNIQUE K2. Для чего может потребоваться перестановка ПК = K2 , UNIQUE = K1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2005, 17:28 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545593]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
141ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
98ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 520ms |

| 0 / 0 |
