Копирование базы данных дизайн базы данных

Question

Я пытаюсь создать базу данных, и мне интересно, если мой дизайн имеет смысл вообще.

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

• Приказ № 1: 100 комплектов 7 B & страниц W и 3 цветных страниц, сшивать, на 8.5x11 бумаге равнины 20lb
• Заказ № 2: Один 24" х 36" плакат ламинированные и установлен на ПЕНОКАРТОН

дизайн я начал работать над этим было:

Так, например, у меня есть:

• продукты: {Копировать заказ, Poster}
• Атрибуты: {B & W Страницы, цвет страницы, наборы, скобозабивные, Формат бумаги, Тип бумаги, плакат Размер}
• Варианты атрибутов: {Скоба верхний левый , ..., 8.5x11, ..., Plain 20lb, ..., 24 "x 36", ...}

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

• Стоимость заказа # 1: [цена B & W отпечатков на обычной бумаге 8.5x11] х [количество B & страниц W] + [стоимость цветной печати на обычной 8.5x11 бумага] x [количество цветных страниц] + [количество комплектов] x [цена скрепки]
• Цена заказа № 2: [цена плаката 24x36, ламинированная и смонтированная на пенопласте] x [количество плакатов]

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

Есть ли разумный способ сделать это в реляционной базе данных? Или я должен сделать это по-другому? Существующая база данных плохо спроектирована (мною несколько лет назад) и имеет большинство атрибутов, жестко закодированных как имена полей, с отдельными таблицами для каждого продукта. Так, например, paper_type - это поле в таблице copy_orders, а poster_size - поле в таблице poster_orders. И я использую код для расчета цены. Я хотел бы создать что-то лучшее и более гибкое.

Я (явно) не эксперт по реляционным базам данных, поэтому любые советы будут очень благодарны! Благодаря!

Answer 1

Ответ, как обычно, «это зависит». Берем первый пример:

The price of Order #1: [price of B&W prints on plain 8.5x11 paper]x[number of B&W pages] + [price of color prints on plain 8.5x11 paper]x[number of color pages] + [number of sets]x[price of staples] 

Вы должны иметь три части (или детали, или продукты, или SKUs): б & ш печать на обычной бумаге, 8.5x11 цветной печати на обычной бумаге 8.5x11 и скрепками. У каждой из этих частей есть цена (есть проблема, связанная с поддержанием истории цен и гарантией того, что вы получите текущую цену за часть, но пока я проигнорирую это).Тогда цена порядка № 1 становится

amount of part1 * price of part1 + 
amount of part2 * price of part2 + 
amount of part3 * price of part3 

Для второго примера, вы должны определить часть под названием «24x36 плакат ламинированной и установлен на ПЕНОКАРТОН», то определить его цену.

Если для атрибутов может быть задан процент (например, цветная печать на 25% больше, чем ab & w print [хотя, возможно, в наши дни это наоборот]), тогда вы определяете часть «print on plain 8.5x11 "и присвойте ему цену. В таблице атрибутов вы добавляете поле «дополнительная дополнительная цена» и вставляете значение 25 (или 0,25 или 1,25, в зависимости от того, как вы хотите управлять вещами) для атрибута «цветная печать».

Для клиентов одним из способов рассмотрения этого является определение постоянной скидки, которую каждый клиент получает из прейскуранта. Если клиенты получают разные скидки на одну часть, тогда у вас нет выбора, кроме как определить таблицу с тремя полями - идентификатором клиента, идентификатором части и ценой.

Хотя это кажется сложным, в конце концов это лучший способ.