Сообщение Как лучше использовать РСУБД для данных с динамической струк от 28.09.2018 9:25
Изменено 28.09.2018 9:26 vsb
Как лучше использовать РСУБД для данных с динамической структурой
Например есть разные типы сущностей, у них разные дополнительные поля (к примеру витрина в магазине, типов товаров может быть очень много вплоть до разделения "процессор", "оперативная память" и тд) и у каждого типа могут быть свои характеристики, по которым потенциально может быть необходимо сортировать, фильтровать и тд. Как для такой задачи лучше организовать схему БД?
1. Для каждой сущности держать отдельную таблицу (ну или одну общую и к ней джойнится куча отдельных). Соответственно при редактировании списка столбцов базе данных высылаются команды вроде alter table. Плюс — БД хорошо делает то, для чего она вроде как предназначена. Минус — замороченность софта а также отдельный запрос на каждую сущность, если грузятся сущности разных типов (ну или миллион left join-ов).
2. Данные хранятся в одной таблице вида (row_id, attr_id, value), по сути таблица разворачивается по столбцам. Плюс — схема БД не меняется, вроде как работать с таким попроще. Минус — наверняка будут запросы, которые тяжело будет оптимизировать.
3. Все динамические столбцы упаковываются в JSON и хранятся в одном поле. Подразумевает современную БД, которая умеет смотреть внутрь JSON-а, например PostgreSQL. Вроде на первый взгляд сплошные плюсы, тут и сортировку можно делать и фильтрацию и индекс создать. Но я с таким никогда не работал и наверняка есть минусы.
1. Для каждой сущности держать отдельную таблицу (ну или одну общую и к ней джойнится куча отдельных). Соответственно при редактировании списка столбцов базе данных высылаются команды вроде alter table. Плюс — БД хорошо делает то, для чего она вроде как предназначена. Минус — замороченность софта а также отдельный запрос на каждую сущность, если грузятся сущности разных типов (ну или миллион left join-ов).
2. Данные хранятся в одной таблице вида (row_id, attr_id, value), по сути таблица разворачивается по столбцам. Плюс — схема БД не меняется, вроде как работать с таким попроще. Минус — наверняка будут запросы, которые тяжело будет оптимизировать.
3. Все динамические столбцы упаковываются в JSON и хранятся в одном поле. Подразумевает современную БД, которая умеет смотреть внутрь JSON-а, например PostgreSQL. Вроде на первый взгляд сплошные плюсы, тут и сортировку можно делать и фильтрацию и индекс создать. Но я с таким никогда не работал и наверняка есть минусы.
Как лучше использовать РСУБД для данных с динамической струк
Например есть разные типы сущностей, у них разные дополнительные поля (к примеру витрина в магазине, типов товаров может быть очень много вплоть до разделения "процессор", "оперативная память" и тд) и у каждого типа могут быть свои характеристики, по которым потенциально может быть необходимо сортировать, фильтровать и тд. Как для такой задачи лучше организовать схему БД?
1. Для каждой сущности держать отдельную таблицу (ну или одну общую и к ней джойнится куча отдельных). Соответственно при редактировании списка столбцов базе данных высылаются команды вроде alter table. Плюс — БД хорошо делает то, для чего она вроде как предназначена. Минус — замороченность софта а также отдельный запрос на каждую сущность, если грузятся сущности разных типов (ну или миллион left join-ов).
2. Данные хранятся в одной таблице вида (row_id, attr_id, value), по сути таблица разворачивается по столбцам. Плюс — схема БД не меняется, вроде как работать с таким попроще. Минус — наверняка будут запросы, которые тяжело будет оптимизировать на стороне БД.
3. Все динамические столбцы упаковываются в JSON и хранятся в одном поле. Подразумевает современную БД, которая умеет смотреть внутрь JSON-а, например PostgreSQL. Вроде на первый взгляд сплошные плюсы, тут и сортировку можно делать и фильтрацию и индекс создать. Но я с таким никогда не работал и наверняка есть минусы.
1. Для каждой сущности держать отдельную таблицу (ну или одну общую и к ней джойнится куча отдельных). Соответственно при редактировании списка столбцов базе данных высылаются команды вроде alter table. Плюс — БД хорошо делает то, для чего она вроде как предназначена. Минус — замороченность софта а также отдельный запрос на каждую сущность, если грузятся сущности разных типов (ну или миллион left join-ов).
2. Данные хранятся в одной таблице вида (row_id, attr_id, value), по сути таблица разворачивается по столбцам. Плюс — схема БД не меняется, вроде как работать с таким попроще. Минус — наверняка будут запросы, которые тяжело будет оптимизировать на стороне БД.
3. Все динамические столбцы упаковываются в JSON и хранятся в одном поле. Подразумевает современную БД, которая умеет смотреть внутрь JSON-а, например PostgreSQL. Вроде на первый взгляд сплошные плюсы, тут и сортировку можно делать и фильтрацию и индекс создать. Но я с таким никогда не работал и наверняка есть минусы.