| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Проектирование БД |
  |
||
 Правильно спроектировать предметную область
|
|
|
ogienko_ev Member Откуда: Сообщений: 5 |
Добрый вечер, есть некая предметная область, в которой основными сущностями выступают: Products Categories Parameters Сущность Products имеет внешний ключ на сущность Categories, т.е. предоставляет какую-либо категорию. Сущность Products должна иметь несколько постоянных параметров, таких как Param #1, Param #2, Param #3 и зависимости от типа категории еще набор параметров Я добавил таблицу CategoryParameters: CategoryParameters Т.е. связываем названия параметров для каждой категории. У каждой категории может быть свой набор параметров. А так, же ProductParameters: ProductParameters Где связываю конкретный продукт с параметрами и назначаю значению конкретного параметра для конкретного продукта. Схема:  Меня беспокоит, что в таблицу ProductParameters можно добавить запись, где продукт связывается с параметром, который не относится к категории, к которой относится продукт. Да, на программном уровне это можно легко обыграть, но меня волнует, как наложить ограничения именно на уровне бд. И вообще адекватное ли решение для данной задачи? Буду благороден помощи. К сообщению приложен файл. Размер - 26Kb |
| 14 авг 19, 20:52 [21949629] Ответить | Цитировать Сообщить модератору | |
| Re: Правильно спроектировать предметную область
|
|
|
SERG1257 Member Откуда: Сообщений: 2667 |
Задлянафига смешивать два понятия параметры для продуктов и категорий. Заведите две таблицы. |
| 14 авг 19, 21:35 [21949641] Ответить | Цитировать Сообщить модератору | |
| Re: Правильно спроектировать предметную область
|
|
|
ogienko_ev Member Откуда: Сообщений: 5 |
SERG1257, В данном случае, сущность параметры для продуктов и категорий одна. Это одно понятие. |
| 14 авг 19, 21:41 [21949645] Ответить | Цитировать Сообщить модератору | |
| Re: Правильно спроектировать предметную область
|
|
|
vmag Member Откуда: MP Сообщений: 3439 |
ogienko_ev, - имхо CategoryParameters - избыточная таблица (то есть таблица состоящая только из FK), ну это как рассматривать просто пару слов Вася + Оля... Кто они? Муж и жена? Брат и сестра? Сотрудники конторы? На основании чего? В какой период? Ну как бэ просто не имеет прямого смысла... - слабое место Categories (с внутренней иерархией и неопределенным количеством уровней иерархии) - если Value разнородное значение, то это или будет Char или в параметры добавлять его тип и попадаем на вложенную иерархию + EAV.... Готов к такому повороту ? К сообщению приложен файл. Размер - 76Kb |
| 15 авг 19, 01:38 [21949712] Ответить | Цитировать Сообщить модератору | |
| Re: Правильно спроектировать предметную область
|
|
|
ogienko_ev Member Откуда: Сообщений: 5 |
vmag, Спасибо большое за ответ, твое решение намного лучше того, что я предложил. На основании твоих доводов, появились ещё вопросы 1) Категории должны иметь иерархию, по предметной области. Если ты говоришь, что вложенность это плохо, как избавится от этой проблемы? Добавить поле веса (уровня)? 2) Изначально, я планировал хранить значения параметров в строке, но подумав, да у параметров могут быть разные типы данных, и теперь как это реализовать? Может вообще стоит отказаться от паттерна EAV и хранить все параметры в таблице продукты? |
| 15 авг 19, 10:58 [21949876] Ответить | Цитировать Сообщить модератору | |
| Re: Правильно спроектировать предметную область
|
|||
|
softwarer Member Откуда: 127.0.0.1 Сообщений: 60440 Блог |
Можно прямым и естественным образом. Добавьте в ProductParameters поле CategoryId. Сошлитесь из неё на Products по составному ключу (ProductId, CategoryId). По этому же составному ключу сошлитесь из ProductParameters на CategoryParameters. Единственно, таким образом Вы не сможете обыграть иерархию в категориях. Декларативные ограничения целостности в СУБД не позволяют проверять принадлежность ветке дерева. Кроме того, существует хакерский путь, которым я пользуюсь в Oracle для того, чтобы декларативно реализовывать "забубенистые" ограничения, не выражаемые нормальными способами (например, вот такую ситуацию с деревом). Для этого я делаю materialized view с опцией refresh on commit. В условиях where я прописываю критерии отбора записей, нарушающих требуемое ограничение (то есть в Вашем случае view должно выдавать записи параметров, в которых категории не соответствуют продукту). А теперь фокус! В части select этого view я пишу что-нибудь типа raise_application_error('Параметр не из той категории!'). И вуаля! Как только меняются данные в одной из задетых таблиц - view пересчитывается, и если в нём появляется хотя бы одна запись - вылетает ошибка и данные не сохраняются. Красота! |
||
| 15 авг 19, 13:05 [21950024] Ответить | Цитировать Сообщить модератору | |||
| Re: Правильно спроектировать предметную область
|
|||||
|
vmag Member Откуда: MP Сообщений: 3439 |
- скорее трудоемко, хотя у тех кто имет опыт работы с этим, особых проблем не возникает, если иерархия очевидна и её можно стандартизировать до 2-х, максимум 3-х уровней, то её можно сделать в виде отдельных таблиц с иерархией.
- нужно смотреть предметную область, опять же... если параметров максимум 10 и больше не предвидится в обозримом будущем, то возможно проще их засунуть в продукты и потом рулить их показом в интерфейсе в соответствии с категориями... |
||||
| 15 авг 19, 13:14 [21950031] Ответить | Цитировать Сообщить модератору | |||||
| Все форумы / Проектирование БД | |
|
x