Представление в БД продукта "Специальные предложения", где специальные предложения зависят от полей - PullRequest
1 голос
/ 27 марта 2011

Я пытаюсь найти наилучший способ представить концепцию «Скидки» в моей базе данных - это относится к «продуктам для продажи». Каждое специальное предложение будет предлагать какую-то скидку, однако они будут различаться в том смысле, что одним будет просто снижение цены, а другими будут такие вещи, как «Купи х, получи полцены» или «30% от категории х». Я не предполагаю иметь более 10 специальных типов ... но требования меняются, и я должен быть уверен, что смогу справиться с ними больше, если возникнет такая необходимость.

Я пытаюсь придумать простой способ их представления в моей БД, однако, как я его вижу, мне либо придется создать таблицу по отдельности, либо мне понадобится таблица со специальными нагрузками столбцов, из которых 90% значений будут NULL. Я намереваюсь иметь таблицу SpecialType, которая сгруппирует все специальные предложения по типу, например «Discount», «Buy x get y Free», и это будет использоваться для определения бизнес-логики на соответствующем уровне приложения. Кроме того, я думал, что смогу пойти по пути, когда у меня есть 1 таблица для каждого специального типа, а затем кэшировать результаты (по сути, кэшировать выводимые данные для каждого продукта), которые можно регулярно обновлять, скажем, каждые 5 минут. выполнять большое количество объединений (РЕДАКТИРОВАТЬ - на самом деле это, вероятно, UNIONS), но делать это довольно редко, поскольку данные не являются критичными в реальном времени в том смысле, что 5-минутная задержка никого не убьет.

Буду признателен за любые отзывы о том, как справиться с этой ситуацией самым аккуратным образом, сохраняя при этом мою базу данных нормализованной.

1 Ответ

0 голосов
/ 27 марта 2011

Поскольку добавление специального типа потребует изменения кода, и вы не можете разумно предвидеть все возможные специальные типы, мне было бы удобно создать отдельную таблицу для каждого типа специальных, наряду с некоторой основной таблицей, котораябудет содержать специальные типы, имена, описания и т. д. *

Использование одной таблицы с большим количеством неприменимых полей может привести к Внутренней платформе , и это почти всегда является избыточным.

Кстати, один из самых неприятных сюрпризов в моей жизни произошел, когда я узнал о новой рекламной акции, требующей изменения кода / базы данных по сравнению с телевизионным рекламным роликом.

...