|
|
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
Кто подскажет, как бороться с полиморф ссылками? Ситуация следующая исходная таблица, кв которой на полиморф указывают две ячейки, первая на таблицу, из которой брать записи, вторая ячейка - номер записи из соответствующей таблицы. Подскажите пожалуйста, как быть? Как побороть такие полиморф ссылки, как лучше перепроектировать несколько таблиц? Заранее благодарен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2006, 23:08 |
|
||
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
Как бороться - перепроектированием :) Сложно универсально ответить на подобный вопрос, не зная задачи. Это все равно как спросить "Как бороться с операторами GOTO в программах?" Например, можно все множество таблиц, на которые идут такие ссылки, обьединить в одну со сквозным ключом, а специфичные для каждой поля хранить отдельно, в таблице вида (тип сущности, id сущности, название поля, значение поля). Но это так, заплатка - скорее всего, изначальный дизайн сделан плохо, надо пересматривать его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 01:20 |
|
||
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
Или как говорит Матроскин или в таблице (в которой хранится связка "номер таблицы+ номер записи") сделать нескольо ссылок на все возможные таблицы. Получится список возможных внешних ключей, но в этом списке все поля кроме одного будут нуловскими. Таким образом можно будет возложить контроль целостности данных на сервер. Но это тоже заплатка. Ваша задача до конца не формализована. Нужно или "добивать" ее до конца (что не всегда реально и нужно), либо бороться вот такими заплатками. Мне больше нравится вариант со списком внешних ключей -- меньше шансов "потерять" связи, которые потом ручками придется восстанавливать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 09:12 |
|
||
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
Если это сделано не со зла:), то никак. Очевидно дизайн приложения исходит из того, что набор таблиц может неограниченно расширяться в силу каких-то неподконтрольных нам причин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2006, 12:27 |
|
||
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинНапример, можно все множество таблиц, на которые идут такие ссылки, обьединить в одну со сквозным ключом, а специфичные для каждой поля хранить отдельно, в таблице вида (тип сущности, id сущности, название поля, значение поля). В вашей таблице тип поля значение поля какой будет? Нужен универсальный какой-то тип, чтобы и VarChar2 хранил, и DateTime, и Number; такого типа по-моему, не бывает. Сержсделать нескольо ссылок на все возможные таблицы Проблема в том, что набор этих всевозможных таблиц, которые представляют одну сущность, может изменяться. А применять каждый раз на рабочей базе операторы ЯОД считаю признаком криво спроектированной БД. ModelRЕсли это сделано не со зла:), то никак. Очевидно дизайн приложения исходит из того, что набор таблиц может неограниченно расширяться в силу каких-то неподконтрольных нам причин. Неужели действительно никак? Теория реляционных баз данных тут сдаётся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2006, 07:48 |
|
||
|
Борьба с полиморф ссылками
|
|||
|---|---|---|---|
|
#18+
CrazyPotato В вашей таблице тип поля значение поля какой будет? Если нужны суммирования, индексирования и т.д. - можно сделать несколько полей "значение" разных типов, или несколько таблиц аналогичной структуры с полями разнх типов, если не нужны - можно все скидывать в varchar. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2006, 13:26 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34062321&tid=1544951]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
173ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 465ms |
| 0 / 0 |
