|
|
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
Друзья, всем доброго времени суток! Возник вопрос, который не дает мне покоя. Имеются объекты, каждый объект относится к какому-либо типу объектов. Каждый объект нужно описывать, но в зависимости от типа объекта, т.е. набор информации для каждого типа объекта уникален. Например, для типа "компьютеры" описываются ОС, IP, MAC, а для типа "телефоны" описываются ОС, IP, провайдер (все это условно говоря). Соответственно есть следующие таблицы: 1. Объекты 2. Типы 3. Таблица для описания типа "компьютеры" 4. Таблица для описания типа "телефоны" 5. Таблица которую я зачем-то сам еще добавил, в которой связывается id типа с id какой-либо из таблиц для описания (на скриншоте будет видно). Вопросы: 1. Взлетит или не взлетит? Если нет, то как можно сделать? 2. Может ли быть из одной таблицы несколько ссылок на другие таблицы? PS: да, можно разделять все программно: "если тип такой, то делаем запрос из таблицы для этого типа, если тип другой, то запрос из таблицы другого типа", но можно ли сделать все проще на уровне БД? PSS: на скриншоте таблица с объектами отсутствует Заранее спасибо, если спрашиваю чушь, то извините :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 07:56 |
|
||
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
G00dWINeВопросы: 1. Взлетит или не взлетит? Если нет, то как можно сделать? 2. Может ли быть из одной таблицы несколько ссылок на другие таблицы? 1. Вполне может взлететь, стандартный паттерн "наследование в РМД". Из неудобств - когда у Вас помимо компьютеров и телефонов появятся планшеты, придется заводить еще одну таблицу и менять код. Зато структура прозрачная и работает б.м. быстро. 2. Да, может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 11:09 |
|
||
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, как бы Вы решили данную задачу? (предполагается, что типы будут добавляться). И какой из вариантов будет работать быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 11:56 |
|
||
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
G00dWINe Кот Матроскин, как бы Вы решили данную задачу? (предполагается, что типы будут добавляться). И какой из вариантов будет работать быстрее? Отвечу за Матроскина по-еврейски. Куда водителю лучше поворачивать направо или налево? Правый поворот будет полегче, значит ли что надо поворачивать всегда направо? А прямо ехать еще легче и быстрее, так может и не надо поворачивать вообще? То есть - для принятия решения информации недостаточно . Что именно будет быстрее - поиск, добавление поддержки нового типа? Я бы посоветовал поискать на этом форуме по слову "наследование", найти реализацию с одной, двумя и тремя таблицами, почитать о достоинствах/недостатках, спроецировать на вашу ситуацию и принять решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 16:49 |
|
||
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
Как я делал подобные вещи: Код: sql 1. 2. 3. 4. Код: sql 1. 2. 3. 4. 5. 6. Код: sql 1. 2. 3. 4. 5. 6. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Из сложностей которые в итоге у меня вылезали это: 1. Параллельная связь с objectTypes(id) у objects(typeID) и objType_properties(typeID), т.е. необходимо перед добавлением данных к объекту проверять что свойство есть среди тех которые приписаны такому то типу объектов. 2. При изменении набора свойств у типа объектов тоже жопа какая-то была. 3. По идее типы значений свойств тоже могут быть разные (числа, тексты, строки, блобы) я это делал коряво конечно, но для меня работало таким образом: В таблице objectType_properties ещё было поле с типом значения свойства (0-INT, 1-FLOAT и т.д.), а в таблице objectProperties были поля не propData а propINT, propFLOAT, propSTRING, propTEXT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2015, 19:57 |
|
||
|
Связь по внешнему ключу к нескольким таблицам
|
|||
|---|---|---|---|
|
#18+
G00dWINe, IMHO проще решать конкретную задачу, чем пытаться сделать "универсальное" решение. Чтобы хранить данные без четко определенной структуры не нужна СУБД. Проще взять что-нибудь типа JSON. А так если все таки хотите "универсальность", то EAV вам в помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2015, 07:31 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=17&tid=1540415]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 374ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...