|
|
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#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 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelRДля плоской системы типов и ролей еще можно применить тот же фокус с константными полями.Чем плохи варианты с такими "константными" проверками. Если программно хочется отработать ошибку вставки, то невозможно будет "предсказать" вставится запись или нет. Проверку на совместимость типов объектов - можно будет только жестко закодировать в программе. Второй вариант - "проверка боем". Вставилась запись - значит типы совместимы, не вставилась - значет не совместимы. Оба варианта - не самые лучшие с точки зрения приложения в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 12:35 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Возможный вариант схемы в прикрепленном файле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 12:50 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
ModelRя бы лучше сказал "ролей"На эту тему есть очень интересные размышления вот здесь - ELIT. ООП и роли , очень жаль что нет продолжения... :( Может кто-нибудь видел (продолжение) ? ModelRДля плоской системы типов и ролей еще можно применить тот же фокус с константными полями.Здорово :) Однако, дополнительное(и малоинформативное) поле role<y>.role_id(=y) на "объектном" уровне - это дополнительные накладные расходы (не ничтожные?). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 13:14 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Ребята не читайте газет во время еды и такие статьи.У вас уже Люди-это Товар,Авто-типы, а Фото-интерфейс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 15:05 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaВозможный вариант схемы в прикрепленном файле ? Файл не прикрепился, возможно, предварительный просмотр "съел", со мной такое случалось:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 15:07 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
База делается на Access, а с SQL-серверами я знаком плоховато. Почитаю про констрэйны, потом выскажусь отдельно. Но, как я понял, целостность надо проверять все-таки кодом? Значит, декларативно – никак. Жаль. Трудновато будет все эти триггеры на Access делать… Да чтобы отрабатывали без проблем… Кстати, тут частенько мелькают типы (что-то вроде _type_), так вроде бы по смыслу это практически тоже самое, что я предложил как ссылка на имя таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 18:25 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Ссылка на имя таблицы увы не катит. Это скорее шаблон DDL. Я в свою очередь мало знаком с ACCESS, но боюсь действительно придется ручками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 18:35 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
КДБаза делается на Access, а с SQL-серверами я знаком плоховато. Почитаю про констрэйны, потом выскажусь отдельно. Но, как я понял, целостность надо проверять все-таки кодом? Значит, декларативно – никак. Жаль. Трудновато будет все эти триггеры на Access делать… Да чтобы отрабатывали без проблем… Кстати, тут частенько мелькают типы (что-то вроде _type_), так вроде бы по смыслу это практически тоже самое, что я предложил как ссылка на имя таблицы?1) в Access нет триггеров, но есть констрэйнты 2) то как показывали - это были именно декларативные ограничения. Просто под разные случаи, с разными ограничениями, достоинствами и недостатками. 3) Ссылка на имя таблицы - это текстовое поле (логическая ссылка). А тип - это сылка по внешнему ключу на таблицу "Справочник типов". В этом справочнике уже может храниться много полезного для работы с типом "Человек" или "Дом". Например, в какой таблице искать доп. данные по этому типу, название типа, название формы - которой можно открыть карточку типа итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2007, 18:44 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 Bely А где это в Access констрэйны? Из справки: Примечание. Ядро базы данных Microsoft Jet не поддерживает использование инструкции CONSTRAINT и всех инструкций языка определения данных (DDL) с базами данных, несовместимыми со стандартом Microsoft Jet. Используйте вместо них методы Create объектов доступа к данным (DAO). Но, м.б., их можно как-то эмулировать? Под словом "декларативно" я подразумевал – только с помощью ключей. > А тип - это сылка по внешнему ключу на таблицу "Справочник типов". > В этом справочнике уже может храниться много полезного для работы с типом "Человек" или "Дом". > Например, в какой таблице искать доп. данные по этому типу, название типа, название формы - которой > можно открыть карточку типа итп. Так если из этой таблицы убрать все, кроме "в какой таблице искать доп. данные по этому типу" – останутся как раз имена таблиц "Люди", "Дома", "Города" и т.д. В таком случае получается, что это моя таблица "Объект"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2007, 18:35 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
К> Автор: КД К> 2 Bely К> А где это в Access констрэйны? Из справки: К> Примечание. Ядро базы данных Microsoft Jet не поддерживает К> использование инструкции CONSTRAINT и всех инструкций языка К> определения данных (DDL) с базами данных, несовместимыми со К> стандартом Microsoft Jet. Используйте вместо них методы Create К> объектов доступа к данным (DAO). Но, м.б., их можно как-то К> эмулировать? Под словом "декларативно" я подразумевал – только с К> помощью ключей. Написано же "несовместимыми со стандартом Microsoft Jet". Ограничения целостности в Access есть и работают через SQL. Документированы, например, в "Microsoft Jet SQL Reference". Хотя то, что там прописано, в полном объеме работает только через ADO. Если Вы используете DAO (собственно сам Access!) или ODBC, то поддерживается ограниченный синтаксис - довольно искусственное усечение (видимо, из ублюдочных маркетинговых соображений)! PRIMARY KEY, NOT NULL, и FOREGN KEY поддерживается при любом интерфейсе. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2007, 19:02 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Dmitriy Ivanov Написано же "несовместимыми со стандартом Microsoft Jet". Ограничения целостности в Access есть и работают через SQL. Документированы, например, в "Microsoft Jet SQL Reference". Хотя то, что там прописано, в полном объеме работает только через ADO. Если Вы используете DAO (собственно сам Access!) или ODBC, то поддерживается ограниченный синтаксис - довольно искусственное усечение (видимо, из ублюдочных маркетинговых соображений)! PRIMARY KEY, NOT NULL, и FOREGN KEY поддерживается при любом интерфейсе.Все правильно, только могу добавить. Поскольку базу создаем сами и руками - незачем в Access писать скрипт создания таблиц через SQL команды. Делаешь все через ихние визарды - и будут ограничения целостности, индексы и констрэйнты. Вобщем и здесь нет проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2007, 10:02 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Недавно, оказывается, появились в Access (с 2002) и CONSTRAIN'ы! Повнимательнее прочитал Гетца "Разработка настольных приложений" – можно применять, причем почти также хорошо как и в SQL-серверах (основываясь на данных нескольких таблиц, несколько правил проверки на уровне таблицы, чего, кстати, не обеспечивает пользовательский интерфейс). Только вот применять их можно, кажется, только выполняя CREATE TABLE, тогда как в SQL-серверах можно и после создания и даже отложить выполнение ограничения на какое-то время. Значит, либо переползаем на следующую версию, либо делаем ручками в коде. > Так если из этой таблицы убрать все, кроме "в какой таблице искать доп. данные по этому типу" – останутся как раз имена таблиц "Люди", "Дома", "Города" и т.д. В таком случае получается, что это моя таблица "Объект"? Ну, а по существу-то я прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2007, 06:20 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
И дались тебе эти констрэйнты.Зачем они нужны в твоей задаче? CHECK "name" IN ('house','people',...) никто не делает.Покажи физическую модель,которая сейчас у тебя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 13:32 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaИ дались тебе эти констрэйнты.Зачем они нужны в твоей задаче?foreign key, вообще-то, тоже constraint ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 14:14 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
О чем и речь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 15:51 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
LR SeVaВозможный вариант схемы в прикрепленном файле ? Файл не прикрепился, возможно, предварительный просмотр "съел", со мной такое случалось:) up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 16:53 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaО чем и речь.Тогда как понимать слова: И дались тебе эти констрэйнты.Зачем они нужны в твоей задаче? т.е. внешние ключи фтопку? ню, ню... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 17:10 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
А, что ню, ню? FK, по большому счету, нужны только на этапе проектирования и для самодокументирования структуры БД, в остальном это только тормоза.Для его 4х таблиц это не обязательно.MS Projects, Axapta и иже с ними, обходятся полностью без FK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 17:43 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaА, что ню, ню? FK, по большому счету, нужны только на этапе проектирования и для самодокументирования структуры БД, в остальном это только тормоза.Для его 4х таблиц это не обязательно.MS Projects, Axapta и иже с ними, обходятся полностью без FKЭх, молодость, молодость... посмеялся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 17:46 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Bely SeVaА, что ню, ню? FK, по большому счету, нужны только на этапе проектирования и для самодокументирования структуры БД, в остальном это только тормоза.Для его 4х таблиц это не обязательно.MS Projects, Axapta и иже с ними, обходятся полностью без FKЭх, молодость, молодость... посмеялся +1 - пятница, однозначно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2007, 17:57 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2Bely Еще смешнее,когда администраторы берутся обсуждать структуру БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2007, 12:26 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 SeVa > Покажи физическую модель,которая сейчас у тебя Так в посте от 14 октября привел. Незначимые для обсуждаемой задачи атрибуты опустил, а схема таблиц есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2007, 06:30 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Такой физ.схемы не может быть.Тебе уже правильно заметили, что для FK нужен уникальный индекс. Вопросы: 1.Связка основных сущностей нужна только для фото или есть еще варианты? 2.Зачем для фотографий нужны отношения многие ко многим? Если есть слабые сущности (дом находится в городе, человек проживает в доме) можно обойтись и 1:N.При этом не нужно каждый раз делать привязку изображений каждый раз поновой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2007, 12:18 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 SeVa > Такой физ.схемы не может быть. Почему не может? FK+Ссылка на таблицу образуют составной ключ. Можно сделать и не составным ключом, а просто запретить ввод повторяющихся значений (путем создания составного индекса), а дополнительно назначить PK, что, собственно и показано на схеме, м.б., не очень понятно. > Связка основных сущностей нужна только для фото или есть еще варианты? Пока вроде только для фото. > Зачем для фотографий нужны отношения многие ко многим? Потому что на фотографии могут быть разные объекты (например, человек на фоне дома). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2007, 06:04 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Не понятно, поскольку FK на несколько таблиц одновременно не бывает. Поэтому делают наоборот, PK в основных сущностях уникальны в пределах БД и являются FК на Объект. Если привязка нужна только для фотографий, то на мой вгляд, таб. Объект - только лишнее усложнение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2007, 13:51 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaПоэтому делают наоборот, PK в основных сущностях уникальны в пределах БД и являются FК на Объект.Если при этом связь "чисто логическая" - то каким образом будет находиться нужная таблица? Вот есть у нас таблица "Телефоны" и есть у нее ссылка на 10 таблиц "Физлица", "Организации" итп. Как найти на какой имеено объект ссылается телефон, если есть номер? Перебирать все 10 таблиц "а где у нас такой PK имеется"? А если добавить поле "название таблицы для ссылки" - то надобность в сквозной нумерации во всей базе отпадает. Ну и к чему Ваш совет тогда был? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2007, 14:54 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
On Fri, 09 Nov 2007 14:54:07 +0300, Bely <nospam@sql.ru> wrote: > Автор: Bely > SeVa > Поэтому делают наоборот, PK в основных сущностях уникальны в пределах БД > и > являются FК на Объект. > Если при этом связь "чисто логическая" - то каким образом будет > находиться > нужная таблица? > > Вот есть у нас таблица "Телефоны" и есть у нее ссылка на 10 таблиц > "Физлица", "Организации" > итп. > Как найти на какой имеено объект ссылается телефон, если есть номер? > Перебирать все 10 таблиц "а где у нас такой PK имеется"? > > А если добавить поле "название таблицы для ссылки" - то надобность в > сквозной > нумерации во всей базе отпадает. > > Ну и к чему Ваш совет тогда был? > Тема Ответить Сообщение "название таблицы для ссылки" - это атрибут Объекта, а не таблицы с FK на нее. CREATE TABLE Objects ( id INT PRIMARY KEY IDENTITY, tableName SYSNAME ); CREATE TABLE Human ( id INT PRIMARY KEY REFERENCES Objects(id) ); CREATE TABLE House ( id INT PRIMARY KEY REFERENCES Objects(id) ); CREATE TABLE ObjectsInPhoto photoId INT REFERENCES Photo(id), objectId INT REFERENCES Object(id) ); -- Здесь у нас туманы и дожди, здесь у нас холодные рассветы, Здесь на неизведанном пути ждут замысловатые сюжеты! Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2007, 20:37 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
BelyВот есть у нас таблица "Телефоны" и есть у нее ссылка на 10 таблиц "Физлица", "Организации" итп. Как найти на какой имеено объект ссылается телефон, если есть номер? Перебирать все 10 таблиц "а где у нас такой PK имеется"? Уникальность как раз и позволяет избежать подобных извратов.Это будет тривиальный join одной view c таблицей телефонов. А вот мне хотелось бы посмотреть, как тебе поможет TableName если усложнить задачу - выводить не название таблицы, а более вразумительную информацию: ФИО, название организации и тд.Причем один телефон может быть у разных объектов(такие варианты могут быть для фотографий, которые здесь и обсуждаются) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 12:09 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa BelyВот есть у нас таблица "Телефоны" и есть у нее ссылка на 10 таблиц "Физлица", "Организации" итп. Как найти на какой имеено объект ссылается телефон, если есть номер? Перебирать все 10 таблиц "а где у нас такой PK имеется"? Уникальность как раз и позволяет избежать подобных извратов.Пример схемы и запроса "узнать тип объекта" - можете привести? А то пока все слова, да слова... SeVaЭто будет тривиальный join одной view c таблицей телефонов. А вот мне хотелось бы посмотреть, как тебе поможет TableName если усложнить задачу - выводить не название таблицы, а более вразумительную информацию: ФИО, название организации и тд.Вы не поверите - будут точно такие же элементарные JOIN-ы Код: plaintext 1. 2. 3. SeVaПричем один телефон может быть у разных объектов(такие варианты могут быть для фотографий, которые здесь и обсуждаются)То же самое, только тип объекта (можно использовать название таблицы) указывается в связующей таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 12:21 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
BelyПример схемы и запроса "узнать тип объекта" - можете привести? А то пока все слова, да слова... Ворос абстрактный и для клиентских запросов он не нужен. SELECT * FROM View WHERE Uid = @Uid.Хотя признак к какому объекту относится запись в табл. Объект у меня присутствует, но с одним существенным отличием,этот атрибут-целое число. По одной простой причине,такая таблица - узкое место, которое должно быть максимально оптимизированно и varchar'ам там не место, для них резервируется пустое место и индексы уж больно пухлые будут. BelyВы не поверите - будут точно такие же элементарные JOIN-ы Да, джойны будут элементарные, но километровые и при добавлении нового объекта их всех прийдется переписывать.Если нравится вариант, когда нужно перелопачивать сотни запросов, мне добавить нечего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 13:32 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaХотя признак к какому объекту относится запись в табл. Объект у меня присутствует, но с одним существенным отличием,этот атрибут-целое число.Мы говорим про наличие/отсутствие такого атрибута, а не про какого типа он должен быть. Вы же говорили - что достаточно одного уникального PK по всей базе. Теперь оказывается уже не достаточно. Зачем такое надо? Ответ простой - программе надо узнать какую форму открыть, если пользователь пытается открыть объект из общего списка объектов. т.е. надо знать тип объекта. SeVaДа, джойны будут элементарные, но километровые и при добавлении нового объекта их всех прийдется переписывать.Если нравится вариант, когда нужно перелопачивать сотни запросов, мне добавить нечего.1. Откройте для себя VIEW :) 2. Все зависит от дизайна - если добавление типа ведет к перелопачиванию всего - то это проблема дизайна. При схеме описанной мной (как оказалось - и Вашей в том числе) - перелопачивать придется только то, что использует все типы сразу. А таких мест, как правило, не очень много. И там будет происходить, как правило, добавление функционала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 13:54 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
1.Я не говорил об одном уникальном PK(такой вариант возможен, но опять же, это может быть узким местом). 2.Открывать весь список и ставить varchar - полный моветон.Это можно делать только на игрушечных БД. 3. автор1. Откройте для себя VIEW :) Приведите примеры запросов для поиска по телефонам и ,скажем, по адресам, с выводом дополнительной информации(думаю, вывод списка Он, Она, Оно будет мало информативен для пользователя)?Что нужно будет сделать с ними при добавлении нового объекта? Вопрос о дизайне я не задаю, думаю, и так все будет ясно после ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 14:46 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa1.Я не говорил об одном уникальном PK(такой вариант возможен, но опять же, это может быть узким местом). Перечитайте... SeVaНе понятно, поскольку FK на несколько таблиц одновременно не бывает. Поэтому делают наоборот, PK в основных сущностях уникальны в пределах БД и являются FК на Объект. SeVa2.Открывать весь список и ставить varchar - полный моветон.Это можно делать только на игрушечных БД.300 тыс строк - проблем не было. Что касается индексов - не стоит забывать, что 4-х символьная строка - не сильно отличается по размеру от INTEGER-а. SeVa3. автор1. Откройте для себя VIEW :) Приведите примеры запросов для поиска по телефонам и ,скажем, по адресам, с выводом дополнительной информации(думаю, вывод списка Он, Она, Оно будет мало информативен для пользователя)?Что нужно будет сделать с ними при добавлении нового объекта? Вопрос о дизайне я не задаю, думаю, и так все будет ясно после ответа.Ладно, напишу еще один студенческий запрос (от Вас так ничего и не дождался... может запросы писать не умеете? :) ). Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 15:00 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. в другом топике было сказано: авторЭто бывает удобно. Например: Таблица ОБЪЕКТ, в которой записано название, тип и прочие общие св-ва объекта. Например, у нас в системе есть объект: Дом, Организация, Человек. Для дома нам надо хранить его: адрес, координаты на карте, план помещений (файл). Для организации: ИНН, счет и пр. реквизиты. Для человека: ФИО, пол, телефон, личный e-mail итп. Для каждого типа объекта - в таком случае можно создать по отдельной таблице в которой будет храниться эта информация. И получится, что во всех этих трех таблицах первичный ключ совпадет с внешним ключем. В схеме чуть выше, в ОБЪЕКТЕ никаких фотографий и номеров телефонов не присутствовало. А теперь всплывает obj_type в телефонах. PS. А что у вас пользователи делали с 300000? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 15:40 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaУгу.Для внятности еще хотелось бы и схему БДЯ, к сожалению, не имею достаточно свободного времени, что полностью задокументировать и привести все свои элементарные примеры - чтобы избежать Ваших придирок. Примерную схему - приводил чуть выше. Далее - все примеры надо рассматривать в контексте разговора. SeVaВ схеме чуть выше, в ОБЪЕКТЕ никаких фотографий и номеров телефонов не присутствовало.А теперь всплывает obj_type в телефонах.Если у нас есть таблица OBJECTS (единый реестр объектов) - то все эти связки пот типу между разнородными таблицами - не нужны. Все связи проводятся через эту центральную таблицу. Если такой таблицы нет - то тогда необходимо в связующих таблицах с логической связью - держать поле "ТИП СВЯЗАННОГО ОБЪЕКТА". И вообще - все это было ответом, на "Поэтому делают наоборот, PK в основных сущностях уникальны в пределах БД и являются FК на Объект." Так вот: я говорил, что единая нумерация объектов во всей БД 1) этого не достаточно 2) Можно обойтись и без нее (нумеровать объекты внутри своей таблицы) остальное - см. выше. SeVaPS. А что у вас пользователи делали с 300000?Обрабатывали эти данные, что же еще :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 15:52 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Меньше смайлов и "логических связей", а больше конкретики. А то описывается одна схема, а запрос из другой оперы(думаю, уже понятно почему,если нет,то не стоит и продолжать). Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 16:16 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVaМеньше смайлов и "логических связей", а больше конкретики.Где же, уважаемый, Ваша схема? Ее так просили показать, но никто не дождался... Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 16:20 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Ерничать время нашлось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 17:13 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa, задокументируйте, пожалуйста, Вашу схему и опубликуйте ее в разделе "Антипаттерны" и "Черный юмор". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 17:27 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Ну, вот guest объявился.Я предупреждал. Это логическая схема, физических реализаций может быть вагон и маленькая тележка.Достоинства и недостатки стратегий: -одна таблица на подкласс -одна таблица на классовую иерархию -одна таблица на конкретный класс давно уже обсосаны и абстрактное обсуждение их мало интересно, особенно в камотозном стиле . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 18:39 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa Это та самая давно обещанная схема или другая? Не вижу в ней решения для обсуждавшейся коллизии... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 18:39 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
А почему б дискриминатор не завести - в Erwin кажись они даже на уровне нотации поддерживались? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 18:57 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa, достоинств в Вашей схеме нет. Ни одного. Абсолютно тупая а-ля Тенцер структура. В общем, аФФтАр, пЕши ИСЧО. А лучше - задокументировать и опубликовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2007, 19:15 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 Bely > Вы не поверите - будут точно такие же элементарные JOIN-ы. Отлично сказано! 2 guest_20040621 А что Вы скажете о моем варианте (см. начало топика)? Только сразу предупреждаю – это непромышленная система, а для домашнего пользования, где я сам во всех ролях – от проектировщика до пользователя. Хотя согласен, что проектировать надо в любом случае "чтоб из пушки стрелять". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2007, 06:04 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
> для домашнего пользования А зачем Вам для домашнего пользования база данных? Может, задачу можно проще решить? > проектировать надо в любом случае "чтоб из пушки стрелять" Абсолютный результат требует бесконечного времени. Не бывает идеальных решений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2007, 08:00 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Абсолютный результат требует бесконечного времени. где почитать доказательство этого утверждения :) ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2007, 09:29 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
Чендлергде почитать доказательство этого утверждения :) ??? Для этого достаточно почитать топики guest'a aka Shuklin изобретателя "однопользовательской файловой desktop базы" с "наличием миллионов threads одновременно"(To guest. Для каких воробьев это нужно?) Там много интересного, не пожалеете. Shuklin, жду продолжения! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2007, 13:24 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
SeVa Для этого достаточно почитать топики guest'a aka Shuklin мне надо это для того чтобы если не успеваю по срокам то было что ответить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2007, 10:41 |
|
||
|
Связывание таблиц различных объектов с одной
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 > А зачем Вам для домашнего пользования база данных? Может, задачу можно проще решить? Я видел, как люди "базу" ведут на карточках. Знаете, таких, библиографических Я уж лучше на компьютере… > Абсолютный результат требует бесконечного времени. Не бывает идеальных решений. "Будем делать хорошо, а плохо само получится" (не помню, кто сказал). А по теме что-н.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2007, 08:25 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1544188]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
164ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
117ms |
get tp. blocked users: |
2ms |
| others: | 193ms |
| total: | 515ms |

| 0 / 0 |
