ник: divino74
решусь спросить, но согласен и на ключ от квартиры где деньги лежат...
покупаем комплектующие, производим товары под заказ
один товар имеет индивидуальный набор комплектующих.
кодировать товары по всем возможным сочетаниям не представляется возможным
из-за огромного кол-ва вариантов.
поэтому комплектующие имеют точное описание, готовая же продукция должна представлять собой некий "шаблон", описывающий скажем только модель изделия, а все его прочие характеристики и, как следствие, комплектующие, должны определяться в момент оформления заказа.
имеем
1. товары
- каждый товар (готовое изделие или компонент) может иметь свой перечень свойств
- свойства могут иметь различный тип данных
числовое (размеры, вес, срок хранения и тд)
string (цвет, модель, вкус, материал и тд)
boolean (услуга да/нет, активный да/нет и тд)
и прочие.
2. группы товаров
- у каждой группы тоже свой перечень свойств, общих для товаров этой группы.
3. каждое свойство имеет определенный перечень значений вообще и
4. для каждого товара должен быть определенный список значений каждого свойства.
5. в момент ввода заказа, задаем свойства товара (готовой продукции), при этом у каждого товара заказа свой перечень свойств.
6. в дальнейшем, исходя из модели изделия и значений его свойств, составляем спецификацию, которую потом резервируем на складе, перемещаем и тд....но это уже производство и складской учет и пока не об этом...
хотел бы услышать мысли и советы по структуре
- tbl товары
*idGood
- tbl типы свойств
*idPropertyType
- tbl свойства
*idProperty
- tbl значения свойств (как описать разные типы данных?)
* idPropValue
idProperty
Value
- tbl свойства товаров
*idGood
*idProp
- tbl заказы
*idOrder
- tbl строки заказов
*idOrderRow
idOrder
idGood
- tbl значения свойств строк заказа
*id
idOrderRow
idPropValue
только не бейте, я только учусь.
спасибо