|
|
|
Правильно ли конструировать модель БД таким образом?
|
|||
|---|---|---|---|
|
#18+
Добрый день Товарищи! У меня такой вопрос. Часто бывает необходимо хранить в базе такую схему: В базе хранятся объекты, каждый объект какого-то типа. И тип не просто поле в таблице объекта, а отдельная таблица. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. В этих объектах, в зависимости от типа, могут быть разные подобъекты (только 1 уровень вложенности, никакого дерева). Эти подобъекты тоже имеют типы, и у каждого типа объекта1 могут быть подобъекты определённых типов. Т.е. есть таблица типов2 и связь между тем, какие типы2 могут быть для каждого типа1 : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. И соответственно таблица хранящая объекты2 : Код: sql 1. 2. 3. 4. 5. 6. 7. Сразу скажу, объекты1 и объекты2 совершенно разные сущности, поэтому нельзя в одной таблице хранить и те и другие. В дальнейшем на них ссылаются разные внешние ключи из других таблиц. Так вот что меня смущает: В таблице Объекты2 имеется некоторая возможная логическая ошибка, ссылка на родительский объект1 автоматически определяет набор доступных типов2 для элемента. Я конечно при добавлении объекта2 в таблицу проверяю чтобы тип2 был из числа доступных для типа родительского объекта, но какое-то нервирующее чуство изъяна не покидает меня в этой схеме. Какое-то закольцевание в этой схеме. Скажите пожалуйста, корректно ли такое хранение для описанного случая? Или это стоит делать каким-то другим способом? Повторюсь, что типы должны быть таблицами а не только полями у объекта. И есть ли на уровне БД в MySQL возможность проверять при добавлении Объекта2 корректность указанного типа2 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2016, 23:05 |
|
||
|
Правильно ли конструировать модель БД таким образом?
|
|||
|---|---|---|---|
|
#18+
В описываемой схеме я не понимаю, почему указание, что тип2 является свойством тип1 , вывалено в отдельную таблицу. Или тип2 может быть подобъектом нескольких различных тип1 ? Если так - рекомендую модифицировать схему. Тип1 сделать абстрактным, т.е. экземпляров такого объекта не существует, в нём только хранятся сведения о возможных для этого типа подобъектах. Включая и САМ ОБЪЕКТ. Т.е. создать экземпляр объекта тип2 , который собственно и хранит экземпляр сущности типа тип1 . Это уведёт тебя от хранения объектов на двух уровнях структуры, что даст возможность отслеживать непротиворечивость штатными средствами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2016, 23:37 |
|
||
|
Правильно ли конструировать модель БД таким образом?
|
|||
|---|---|---|---|
|
#18+
Блин, с форматированием, ессссно, накосячил. 2Модератор: если будет несложно, замените теги кода на жирность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2016, 23:38 |
|
||
|
Правильно ли конструировать модель БД таким образом?
|
|||
|---|---|---|---|
|
#18+
PS. Единственная проблема, которая у тебя останется - как отслеживать, что "куст" экземпляра тип1 содержит базовый экземпляр тип2 , причём строго один. Боюсь, штатные средства этого не позволят. А при попытке ввести обратные линки ты опять вернёшься к "кольцу". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2016, 23:42 |
|
||
|
Правильно ли конструировать модель БД таким образом?
|
|||
|---|---|---|---|
|
#18+
Akina спасибо за ответ! Сейчас постараюсь осмыслить предложенное. По поводу отдельной таблицы для тип2 , да у разных типов1 могут быть одни и те же типы2 . Akina , я несколько раз перечитал твой пост, но не смог понять что сделать. Где хранится связь объекта1 с объектом2 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2016, 23:43 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39337113&tid=1831262]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 484ms |

| 0 / 0 |
