Здравствуйте, Alex Warm, Вы писали:
G>>В принципе можно для типа товара задать xml схему, а для каждого товара хранить параметры в xml. Для подбора по параметрам использовать генерируемый xpath запрос. AW>Повторюсь — хочется реализовать в EF модели. Реализовать без нее не проблема.
Если хочется именно в EF, то создавай колонки, ниче кардинально лучше ты не придумаешь.
Здравствуйте, Alex Warm, Вы писали:
I>>С этим "стандартно" вся загвоздка
AW>ээээ... простите, может я не знаю чего, но вроде как конструкцию (для штрихкода к примеру) AW>
-_*>Здравствуйте, Alex Warm, Вы писали:
I>>>С этим "стандартно" вся загвоздка
AW>>ээээ... простите, может я не знаю чего, но вроде как конструкцию (для штрихкода к примеру) AW>>
-_*>А у меня в проекте нет такой конструкции, а баркоды, прайсы — есть
-_*>И странно кк то — у прайса есть поле баркод — что это ?
упс... не Price конечно, а Commodity
как раз отвлекли вот и лопухнулся.
TodayPrice — это текущий прайс с ценами на текущую дату.
Состоит из собственно товаров (Commodity) с единицами измерения и ценами. Штрихкод привязан к единице.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Alex Warm, Вы писали:
G>>>В принципе можно для типа товара задать xml схему, а для каждого товара хранить параметры в xml. Для подбора по параметрам использовать генерируемый xpath запрос. AW>>Повторюсь — хочется реализовать в EF модели. Реализовать без нее не проблема. G>Если хочется именно в EF, то создавай колонки, ниче кардинально лучше ты не придумаешь.
То есть более менее сложносвязную схему в EF реализовать не получится?
Здравствуйте, Alex Warm, Вы писали:
AW>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Alex Warm, Вы писали:
G>>>>В принципе можно для типа товара задать xml схему, а для каждого товара хранить параметры в xml. Для подбора по параметрам использовать генерируемый xpath запрос. AW>>>Повторюсь — хочется реализовать в EF модели. Реализовать без нее не проблема. G>>Если хочется именно в EF, то создавай колонки, ниче кардинально лучше ты не придумаешь. AW>То есть более менее сложносвязную схему в EF реализовать не получится?
Схему любой степени связности получится, только схема должна быть фиксирована на момент компиляции. Причем это требование не только для EF, а почти для любого маппера.
Мой опыт создания всяких каталогов говорит что фиксированных схем в магазинах почти не бывает.
Здравствуйте, Alex Warm, Вы писали:
AW>Добрый день. AW>Пожалуйста помогите реализовать в модели следующий принцип: AW>Есть базовый тип товара (к примеру ботинки,куртка и т.д.) AW>Базовый тип может иметь произвольные назначаемые свойства-модификаторы (размер, цвет, рост и т.п.) AW>с учетом данных модификаторов, должна получиться торговая позиция (ботинки черные 46 размера) на которую уже дальше можно будет назначать цену и т.п.
У нас тоже сложный справочник материалов (товаров), разбили его на группы, подгруппы.
В каждой подгруппе свой перечень характеристик материала (размеры, формы, госты, состав, ...) тут никуда не денешься, либо отдельными таблицами, либо XML
В ER-диаграмме это таблица Материалы(Подгруппа, Наименование, Полное наименование, Ед. Измерения) и Характеристики(Материал, Тип хар., Значение)
"Полное наименование" — Это поле заполняется по триггеру "Наименование" + все Характеристики через пробел (или запятую, или по шаблону).
Создали универсальную форму поиска, в которой при выборе группы-подгруппы в гриде появляются дополнительные колонки с характеристиками по которым можно искать
На практике схема со сложным гридом не пригодилась.
Сейчас сделали простую форму поиска, только: УИ, Группа, Подгруппа, Полное наименование. Пользователь кратко через пробел (в любом порядке) вводит характеристики материалов, алгоритм ищет вхождения искомых слов по строке "Полное наименование" из 20000 позиций. Все довольны
