|
|
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Имеется несколько разных таблиц для разных объектов (например, Люди, Дома, Города) и таблица со ссылками на фотографии этих объектов. Если бы объекты были однородными (например, только Люди), я бы сделал классическую схему "многие-ко-многим". А сливать такие разные объекты не хочется, т.к. не хочется валить в одну кучу совершенно разные атрибуты. Пожалуйста, подскажите что-н. толковое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 06:31 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 08:30 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
например, как описано здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 09:38 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Я правильно понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2007, 06:12 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Неправильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2007, 10:27 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Можно, конечно, и так - но есть способ (куда) лучше. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2007, 10:31 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Сейчас проснется guest_ или выйдет из камотоза и прочтет лекцию о не знании основ ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2007, 11:53 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 Bely Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2007, 15:50 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Я, пожалуй, не буду дожидаться guest'а: 2 Bely Объясните, пожалуйста, как Вы собираетесь поддерживать ссылочную целостность в предложенной Вами схеме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 06:07 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR2 Bely Код: plaintext 1. 2. В быту - headershoulder В ООП - множественное наследование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 09:54 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR2 Bely Код: plaintext 1. 2. Знаете способ лучше? Поделитесь... КДОбъясните, пожалуйста, как Вы собираетесь поддерживать ссылочную целостность в предложенной Вами схеме?так Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 10:20 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR2 Bely Код: plaintext 1. 2. ALTER TABLE object CREATE CONSTRAINT check_tblnames CHECK "name" IN ('house','people',...) и добавлением скажем триггерной проверки к ФК табличек (то,что существует именно строка с таким именем и значением id). с другой это лечится еще и: 1. либо разделением неперекрывающихся диапазонов для house.id people.id ... (несколько способов, в т.ч. - (триггерное) пользование общего счетчика), или прорежением счетчика ~~ DEFAULT nextval('...')* основание + остаток сравнения (+ такой же чек на каждую таблу). 2. либо добавлением константного поля во все таблицы (и в их первичные ключи, на лидирующей позиции, ес-нно). (что несколько раздует все данные и индексы), но проще при уже заполненной базе, где разделение диапазонов id не обеспечивалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 11:07 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Вместо Name короче и суше ObjectTypeId- FK на таблицу ObjectType (ObjectTypeId,TableName) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 13:04 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
BelyПоделитесь...? Код: 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. 2 SeVa Если уж сушить, то пары ObjectType (ObjectTypeId,TableName) вполне можно добывать из словаря СУБД - если придерживаться определенного соглашения об именах объектов словаря. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 14:54 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR 2 4321 автор2. либо добавлением константного поля во все таблицы (и в их первичные ключи, на лидирующей позиции, ес-нно). не понял, зачем в ПК всех таблиц.по большому - незачем , ибо, вообще говоря достаточно повесить индекс на пару (тип, ид) (для оптимайза джойнов, а то оптимайзер может не прочухать), но т.к. индекс по ключу и так создается - всунуть в ключ и тип - сэкономить на индексах. (хотя вру, скорее всего ид-ки пипплов и тп. будут еще где-нито провязаны в 1-много без константных типов, т.ч. уникью на ид-ник придется вешать отдельно... видимо да, в ключ - незачем. просто создать индексы (тип, ид)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 17:42 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR...Ну это практически одно и то же. И самое главное - не то, что собирался делать автор. Автору, наверно, подойдет больше Ваш вариант. PS: это лишнее :) Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 19:28 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
BelyPS: это лишнее :)дык без него как ALTER TABLE anketa_auto ADD CONSTRAINT fk_uq1_ank_head FOREIGN KEY (ank_id, ank_type_id) REFERENCES anketa_head ( ank_id, ank_type_id ) за што собственно и боролися. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 11:31 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR BelyPS: это лишнее :)дык без него как ALTER TABLE anketa_auto ADD CONSTRAINT fk_uq1_ank_head FOREIGN KEY (ank_id, ank_type_id) REFERENCES anketa_head ( ank_id, ank_type_id ) за што собственно и боролися.Уникальность ank_id - гарантирует primary key. Соответственно - любая комбинация с ним будет уникальна, либо просто не вставится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 13:18 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
pkarklin Код: plaintext 1. 2. 3. 4. 5. 6. 7. +1 Нужна объединяющая разнородные понятия сущность - "объект" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 13:42 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Bely любая комбинация с ним будет уникальнаматематический факт. Однако SQL серверы этого не знают:( . Оне соглашаются принять FK только на явно объявленный UNIQUE / PK . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 15:45 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR Bely любая комбинация с ним будет уникальнаматематический факт. Однако SQL серверы этого не знают:( . Оне соглашаются принять FK только на явно объявленный UNIQUE / PK .понятно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 16:01 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelR Код: plaintext 1. 2. 3. В обсуждаемой схеме прослеживаются два "вида" таблиц: один - это "домашние таблички типов" (Люди, Дома, Города, Авто) второй - таблички "интерфейсов" (Фото, пусть еще для примера - Товар) Допустим, все четыре "типа" поддерживают "интерфейс" Фото, и только Дома и Авто поддерживают Товар, т.е. в "интерфейсных" таблицах будут ограничения типа: ... type_id ... CHECK (type_id in(Люди, Дома, Города, Авто) ) - для Фото ... type_id ... CHECK (type_id in(Дома, Авто) ) - для Товара В какой-то момент пользователь системы решил, что Города - не тот тип, который можно представить (одним) Фото, а Люди - как раз тот тип, что может быть Товаром... Придется переделывать ограничения целостности... Понятно, что для табличек-"типов" такая ситуация маловероятна. А вот для табличек-"интерфейсов" такая схема ссылочной целостности выглядит слишком "жесткой", imho. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 18:57 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
LRВ какой-то момент пользователь системы решил, что Города - не тот тип, который можно представить (одним) Фото, а Люди - как раз тот тип, что может быть Товаром... Придется переделывать ограничения целостности...Тут надо решить что именно и как легко может менять пользователь. Можно привести другие примеры - Хочется ввести не просто человека, а разделить на "Сотрудника", "Клиента" итд. Для э того придется вводить новый тип и... переделать ограничения целостности. Поэтому если типы будут меняться часто - то констрэйнты будут только мешать. Но у автора топика - ситуация, скорее, обратная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 19:11 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#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. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. Т.е., грубо говоря, добавить еще один мета-слой (топологически, таблично напоминающий "объектный"), тогда, добавляя/удаляя записи в таблицы_meta, мы сможем регулировать(не изменяя структуру/код) ограничения целостности... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2007, 19:32 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Нет предела совершеству. Кроме ограничения сочетаний "интерфейсов" (или я бы лучше сказал "ролей" - все же это не программные интерфейсы) с типами можно потребовать ограничить сочетаемость ролей между собой. А когда вдруг роли и типы начнут плодиться как кролики -построить иерархию типов и классификацию ролей т.д. Для плоской системы типов и ролей еще можно применить тот же фокус с константными полями. псевдокод для краткости Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ну а дальше - дешевле сделать кодом промежуточного слоя ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 12:11 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34872068&tid=1544188]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
195ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 554ms |

| 0 / 0 |
