| |
|
|
| | решусь спросить, но согласен и на ключ от квартиры где деньги лежат...
покупаем комплектующие, производим товары под заказ
один товар имеет индивидуальный набор комплектующих.
кодировать товары по всем возможным сочетаниям не представляется возможным
из-за огромного кол-ва вариантов.
поэтому комплектующие имеют точное описание, готовая же продукция должна представлять собой некий "шаблон", описывающий скажем только модель изделия, а все его прочие характеристики и, как следствие, комплектующие, должны определяться в момент оформления заказа.
имеем
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
только не бейте, я только учусь.
спасибо | |
| |
| |
|
|
| |
|
|
| | по VBA, может небольшие , но познания есть....
еще раз попробую на примере:
предположим я изготавливаю игрушки из детского конструктора lego:
у меня куча типов деталей (кубиков). каждый кубик имеет такие свойства как
форма, цвет, размер и пр.
из кубиков я делаю самые разные игрушки, например машинки и домики
машинки, как готовое изделие имеют свои свойства: марка, модель, цвет, и тд. (и если забыть, что пример об игрушечном авто, то еще мощность, тип двигателя и тд и тп)
домики же совсем свои (опять же если абстрагироваться от игрушки) тип проекта, кол-во комнат общая площадь, терраса да/нет и тд. и тп.
в общем случае можно сказать, что я не хочу ограничиваться какой-то категорией товаров,
и хотел бы иметь возможность вносить в справочник самую разношерстную продукцию.
в зависимости от свойств машинки я изготовляю ее из тех или иных кубиков (то есть производственная спецификация формируется в зависимости от цвета всей машины и/или отдельных частей, наличия люка на крыше, или отделки салона... напоминаю это все образно!)
запоминать все возможные варианты исполнения нет ни возможности, ни надобности.
поэтому есть идея хранить в справочнике товаров "кубики" с полным и точным описанием, а вот домики и машинки как некий шаблон, скажем машинка
- модель POLO без указания цвета кузова, наличия люка и тд
- модель GOLF
- модель PASSAT
- коттедж проект 12
- коттедж проект 53 и тд.
Для каждого изделия (или хотя бы группы изделий) должен быть определенный список свойств и их возможных значений.
Наконец, при оформлении заказа выбрав скажем POLO, необходимо получить список свойств и задать им определенные значения, согласно которым я потом буду "лепить" эту машинку. Задавать значения нужно только тем свойствам, которые присущи этой модели, а не другим и тем более домикам. от сюда весь вышеописанный набросок таблиц.
считывая значения свойств оператор уже сам знает какие кубики и в каком кол-ве ему понадобятся для производства. | |
| |
| |
| |
|
|
| | Со справочником все правильно. В рабочей форме, после выбора определенного товара, относящегося к определенному типу со своими свойствами, в подчиненную форму вноси наименования свойств запросом на добавление. Однако тут должен быть еще один запрос, на совпадения, что бы каждый раз эти свойства не вносились снова. | |
| |
| |
| |
|
|
| | entity-attribute-value model
почитай, может направит или мысль подкинет | |
| |
| |
| |
 19 Кб. |
|
| | Я имел в виду вот типа такого. Если вообще правильно что понял. 
Специально сделал на открытых запросах, что бы было понятней сама идея.
PS. Тут можно кнопку убрать и запускать запрос сразу, как только ввели новый товар, убрать предупреждающие окна, сделать на списке, что бы нельзя было удалить свойства и запросом на обновление вписывать нужные значения. | |
| |
| |
| |
|
|
| | а что entity-attribute-value model реально реализовывать в access? | |
| |
| |
| |
|
|
| | только с кодом думаю возни будет больше чем обычно, хотя ХЗ
п.с. платформа не суть - суть структура и алгоритм | |
| |
| |
| |
|
|
| | на чистом Access очень хлопотно вести базу токой архитектуры и поддерживать целостность данных | |
| |
| |
| |
|
|
| | иерархические структуры разрулят
другой фопрос - в эффективности работы аксесса с ними
ну или в наличии эффективных алгоритмов....
все в оракл :) | |
| |
| |
| |
|
|
| | прочел шо такое ваш ентот EAV
оказуедза я уже реализовывал это в своих разработках
как в аксессе, так и на php И MySQL
еще помню, на ADP в каком то проекте принимал участие , делали подобное...
для веба более удачно получилось
таблица объектов, таблица связей, таблица свойств, таблица классов (ну, это типа шаблоны объектов - описание стандартных свойств), таблица значений свойств объектов.... ну может еще что.... | |
| |
| |
| |
|
|
| |
прочел шо такое ваш ентот EAV
оказуедза я уже реализовывал это в своих разработках
|
с EAV каждый или уже игрался или еще будет :) | |
| |
| |
| |
|
|
| | та понимаешь.... я уже со многим игрался, а названия этих игрушек потом на собеседовании или от других узнаю :) с удивлением  | |
| |
| |
|
|
