Добрый день.
Пожалуйста помогите реализовать в модели следующий принцип:
Есть базовый тип товара (к примеру ботинки,куртка и т.д.)
Базовый тип может иметь произвольные назначаемые свойства-модификаторы (размер, цвет, рост и т.п.)
с учетом данных модификаторов, должна получиться торговая позиция (ботинки черные 46 размера) на которую уже дальше можно будет назначать цену и т.п.
Здравствуйте, Alex Warm, Вы писали:
AW>Добрый день. AW>Пожалуйста помогите реализовать в модели следующий принцип: AW>Есть базовый тип товара (к примеру ботинки,куртка и т.д.) AW>Базовый тип может иметь произвольные назначаемые свойства-модификаторы (размер, цвет, рост и т.п.) AW>с учетом данных модификаторов, должна получиться торговая позиция (ботинки черные 46 размера) на которую уже дальше можно будет назначать цену и т.п.
Пока не расскажешь как это все будет применяться адекватных ответов не будет.
Здравствуйте, gandjustas, Вы писали:
G>Пока не расскажешь как это все будет применяться адекватных ответов не будет.
ну по сути это база магазина в разрезе товара.
товар естественно лежит на складе, имеет цену, поступает по накладным и продается.
все дальнейшее я представляю как реализовать в модели, а вот именно описанный выше кусок — нет. от взаимных ссылок голова начинает кружиться.
Здравствуйте, Alex Warm, Вы писали:
AW>Здравствуйте, gandjustas, Вы писали:
G>>Пока не расскажешь как это все будет применяться адекватных ответов не будет.
AW>ну по сути это база магазина в разрезе товара. AW>товар естественно лежит на складе, имеет цену, поступает по накладным и продается. AW>все дальнейшее я представляю как реализовать в модели, а вот именно описанный выше кусок — нет. от взаимных ссылок голова начинает кружиться.
ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml.
Здравствуйте, gandjustas, Вы писали:
G>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml.
Понимаешь, на SQL это сделать я могу запросто.
Хочется именно в виде модели (совмещаю приятное с полезным — изучаю и проект неспеша двигаю).
И хочется, что-бы оно работало именно так, как я описал. Есть на то определенные практические моменты. в двух словах — имеется масса однотипной продукции, которая отличается только размером и к примеру упаковкой. что-бы не городить огород со связыванием еще и описаний,фотографий и т.п. и родилась такая структура.
G>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml.
может как раз тут NoSql и помог бы
потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать)
возмите любую document-oriented db и не морочьте никому голову.
Если уж очень хочется сложностей то тогда сразу в RDF делайте
G>>>Пока не расскажешь как это все будет применяться адекватных ответов не будет.
AW>>ну по сути это база магазина в разрезе товара. AW>>товар естественно лежит на складе, имеет цену, поступает по накладным и продается. AW>>все дальнейшее я представляю как реализовать в модели, а вот именно описанный выше кусок — нет. от взаимных ссылок голова начинает кружиться.
G>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>может как раз тут NoSql и помог бы C>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать)
Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице.
Поэтому я вначале и спросил про сценарии использования.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>>может как раз тут NoSql и помог бы C>>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать) G>Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице.
тогда получится куча таблиц, кроме башмаков будет платье, пальто и т.д. G>Поэтому я вначале и спросил про сценарии использования.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
G>>>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>>>может как раз тут NoSql и помог бы C>>>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать) G>>Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице. C>тогда получится куча таблиц, кроме башмаков будет платье, пальто и т.д.
У платьев и пальто тоже есть размер и цвет
Здравствуйте, gandjustas, Вы писали:
G>>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>>может как раз тут NoSql и помог бы C>>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать) G>Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице. G>Поэтому я вначале и спросил про сценарии использования.
Сценарии как я уже говорил самые обычные для магазина.
Что связано с поиском, то тут еще проще — их всего пара
— поиск по штрихкоду (который привязывается к единице товара)
— поиск по производителю и названию, затем уточнение по параметрам.
все это реализовывается стандартно.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>У платьев и пальто тоже есть размер и цвет C>только размер будет типа XL, а ботинки 42
значит параметры должны привязываться к базовому типу и быть разными.
хотя заманчиво их тоже сделать типовыми в какой-то мере, что бы те-же размеры не вбивать для каждого базового типа.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>У платьев и пальто тоже есть размер и цвет C>только размер будет типа XL, а ботинки 42
И что? У ботинок также есть размеры типа 41,5
Ну ты понял о чем я.
Здравствуйте, gandjustas, Вы писали:
G>>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>>может как раз тут NoSql и помог бы C>>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать) G>Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице. G>Поэтому я вначале и спросил про сценарии использования.
А если куртку размера XXL или часы мужские, тоже колонки ?
Сдаётся это тот случай, когда поиск нужен даже если про него никто не говорил.
AW>Сценарии как я уже говорил самые обычные для магазина. AW>Что связано с поиском, то тут еще проще — их всего пара AW>- поиск по штрихкоду (который привязывается к единице товара) AW>- поиск по производителю и названию, затем уточнение по параметрам. AW>все это реализовывается стандартно.
Здравствуйте, gandjustas, Вы писали:
G>>>У платьев и пальто тоже есть размер и цвет C>>только размер будет типа XL, а ботинки 42 G>И что? У ботинок также есть размеры типа 41,5 G>Ну ты понял о чем я.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>ну сделай для каждого товара типа (lookup из другой таблицы) и произвольные свойства в xml. C>>>может как раз тут NoSql и помог бы C>>>потом захочется поиск (найти черные ботинки 46 размера), хотя в mssql вроде есть поиск по xml (xpath запускать) G>>Если хочется искать черные ботинки 46 размера, то можно для этих параметров сделать колонки в таблице. G>>Поэтому я вначале и спросил про сценарии использования.
I>А если куртку размера XXL или часы мужские, тоже колонки ?
Размер уже есть, а "часы мужские" — тип товара, тоже есть.
I>Сдаётся это тот случай, когда поиск нужен даже если про него никто не говорил.
Поиск всегда нужен, полнотекстовый, даже если вообще ниче не говорят. При этом NoSQL тут вообще никаким боком, для этого внешние движки, на крайняк FTS.
А вот нужен "подбор по параметрам". Вот тут уже интереснее. Иметь одни "размер" для маек (S,M,L,XL,XXL), для обуви (есть половинчатые размеры) и для джинсов (вообще пара размеров — рост и ширина) не получится. И нужна схема, которая будет описывать эти самые параметры.
В принципе можно для типа товара задать xml схему, а для каждого товара хранить параметры в xml. Для подбора по параметрам использовать генерируемый xpath запрос.
Учитывая что число товаров на один тип не превышает обычно пару сотен, то вполне можно обойтись тем что я выше написал. Если будет тормозить, то достроить xml-индексы по тормозящим запросам.
Здравствуйте, Ikemefula, Вы писали:
AW>>Сценарии как я уже говорил самые обычные для магазина. AW>>Что связано с поиском, то тут еще проще — их всего пара AW>>- поиск по штрихкоду (который привязывается к единице товара) AW>>- поиск по производителю и названию, затем уточнение по параметрам. AW>>все это реализовывается стандартно.
I>С этим "стандартно" вся загвоздка
ээээ... простите, может я не знаю чего, но вроде как конструкцию (для штрихкода к примеру)
Здравствуйте, gandjustas, Вы писали:
I>>Сдаётся это тот случай, когда поиск нужен даже если про него никто не говорил. G>Поиск всегда нужен, полнотекстовый, даже если вообще ниче не говорят. При этом NoSQL тут вообще никаким боком, для этого внешние движки, на крайняк FTS.
Ну в данный конкретный момент вообще-то речь о полнотекстовом поиске не стоит совершенно. Еще раз повторюсь — система предназначена для ОБЫЧНОГО магазина. Не интернет магазина. А для рабочего места кассира полнотекстовый поиск если и нужен, то только для названия или производителя. А уж для 2-то текстовых полей я FTS как-нибудь реализую.
G>А вот нужен "подбор по параметрам". Вот тут уже интереснее. Иметь одни "размер" для маек (S,M,L,XL,XXL), для обуви (есть половинчатые размеры) и для джинсов (вообще пара размеров — рост и ширина) не получится. И нужна схема, которая будет описывать эти самые параметры.
Почему не получится? делашь типовой параметр РазмерОбуви с полем отображаемое значение "Размер" и добавляешь этот параметр к нужным тебе типовым товарам (Ботинки Rocky)
второй параметр создаешь с именем допустим "Цвет обуви" и добавляешь туда-же.
Получаешь на выходе товар "Ботинки ROCKY" с двумя параметрами — размер и цвет.
Другое дело, как эти параметры заполнять. В идеале нужно иметь список значений, но эти значения не всегда могут совпадать, к тому-же иметь гиганский выпадающий список он никому не нужен. Можно к примеру сделать дополнительное свойство для параметра — "Глобальный" — т.е. имеющий для выбора все значения когда либо вводимые в данный параметр.
В принципе простейший distinct. В противном случае, отбирать значения из параметров присутствующих в данной связке базовый_товар-параметр.
По большому счету не так много там вводить. все равно меньше, чем если каждый товар забивать по отдельности
G>В принципе можно для типа товара задать xml схему, а для каждого товара хранить параметры в xml. Для подбора по параметрам использовать генерируемый xpath запрос.
Повторюсь — хочется реализовать в EF модели. Реализовать без нее не проблема.
G>Учитывая что число товаров на один тип не превышает обычно пару сотен, то вполне можно обойтись тем что я выше написал. Если будет тормозить, то достроить xml-индексы по тормозящим запросам.
В самом худшем случае — 100-120. Обычно намного меньше.
