|
|
|
Как по вашему мнению будет правильнее организовать структуру БД?
|
|||
|---|---|---|---|
|
#18+
Приветствую, значит ситуация следующая, требуется сделать базу для хранения "компонентов". Компонент, это некая графическая абстракция + немного метаинформации. В компоненте есть два символа, т.е само графическое представление. Символ состоит из примитивов, т.е линии, прямоугольников, окружностей и т.д. Сейчас стою перед выбором, как лучше организовать структуру базы под это дело. Вариант 1. Делаем одну общую таблицу примитивов, со столбцами - всеми возможными реквизитами примитивов, т.е всякие X1, X2, Width, Height, Radius и и.т.д Плюс: Всё будет в одной таблице, но в ней будет много "пустого места". Картинка для пояснения: Вариант 2: Для каждого примитива заводим свою таблицу, типа Lines, Rectangles, Circles и т.д В этой таблицу храним реквизиты для каждого примитива + внешний ключ ИД символа, к которому этот примитив принадлежит. Плюсы: вроде как логичней, но минус: усложняется структура, придётся иметь кучу таблиц со связями типа много-ко-многим с таблицей самих символов. Что думаете? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2014, 08:05 |
|
||
|
Как по вашему мнению будет правильнее организовать структуру БД?
|
|||
|---|---|---|---|
|
#18+
Поправочка, во втором варианте, связь один-ко-многим конечно же. Т.к у каждого символа свои уникальные примитивы. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2014, 08:18 |
|
||
|
Как по вашему мнению будет правильнее организовать структуру БД?
|
|||
|---|---|---|---|
|
#18+
I dont know, Конечно же надо использовать наследование, т.е . этот вариант: Для каждого примитива заводим свою таблицу, типа Lines, Rectangles, Circles и т.д В этой таблицу храним реквизиты для каждого примитива + внешний ключ ИД символа, к которому этот примитив принадлежит. Плюсы: вроде как логичней, но минус: усложняется структура, придётся иметь кучу таблиц со связями типа много-ко-многим с таблицей самих символов. Что тут сложного в структуре? 10 табличек всего. В общем, сложность в структуре -- не критерий. Картинки почему-то одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2014, 09:05 |
|
||
|
Как по вашему мнению будет правильнее организовать структуру БД?
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Я не осилил добавление вложения на этом форуме :( Тоже склоняюсь ко второму варианту, буду прорабатывать его ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2014, 09:22 |
|
||
|
Как по вашему мнению будет правильнее организовать структуру БД?
|
|||
|---|---|---|---|
|
#18+
I dont knowКак по вашему мнению будет правильнее организовать структуру БД? В данном случае не видно никаких причин пользоваться средствами "структуры БД". Судя по всему, БД будет использоваться только как свалка данных, для операций "прочитать объект" и "записать объект". В этом случае оптимально хранить "компонент" в поле какого-либо универсального типа данных - XML, BLOB etc., а сериализацию-десериализацию отдать клиенту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2014, 13:46 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1540752]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
8ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 271ms |

| 0 / 0 |

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