Антон Шаманов, Да вчера сервис этот нашел решил что-то набросать. Я просто до этого работал в основном с MODX EVO там EAV реализована вот так как на схеме.
3 таблицы: ресурс (сущность),
одна сводная (ресурс_ид, аттрибут_ид, значение текст поле) +
характеристики (тип(select,checkbox), название, возможные значения списком с разделителями
есть еще группы характеристик которые привязаны к шаблону (например товар/страница) что угодно - набор полей вида select/text и тд можно любые делать и в любом кол-ве. При том что сделано это просто дико универсально. Текущий шоп на модиксе имеет варианты размеров и цены, но это костылем сделано Может по этому отталкиваюсь от этой структуры начальной базы. Но это просто вариант. Сейчас фреймворк, сделать можно уже как угодно, это огромный плюс.
Антон Шаманов, Во тут пример сайт (помоему на битриксе) https://www.bronnitsy.com/catalog/i/koltso-obrucha... - меняется артикул и цена при смене размера кольца. Но если посмотреть в сторону аджакса при изменение поля select, перегружается вообще весь блок с характеристиками (как буд-то бы это вообще отдельная сущность SKU имеющая свои наборы характеристик и привязку к цене).
https://www.bronnitsy.com/catalog/i/braslet-ruchno... - тут меняется еще и перечеркнутая цена. То есть вполне может быть что при выборе размера товара происходит смена варианта товара с произвольными значениями характеристик просто указанных ранее или обьедененных в группу.
Да может не правильно написал я, просто куча вариантов и мысле в голове. 3-й день исследую разные варианты =) По идее это и имел ввиду, из заранее определенных списков с уже добавленными ранее значениями. Там уже не важно как добавленными, через аджакс в процессе создания товара или в разделе "атрибуты - добавить новый - тип список - значения"
Да, группы характеристик будут. Сейчас не стал это включать в вопрос, там мелочь, нет смысла.
Ох как трудно все описать все в чатике, когда у самого нет четкого плана =). То есть, получается тут надо создавать отдельные списки для опций с вариантами значений (размеры изделия (кольца или цепи) + список значений) ? И комбинировать можно будет только их из заранее предустановленных значений ?
Допустим, мы где-то сделали список размеров и список возможных материалов, далее добавили новую опцию выбрали там размер, добавили (если нужно) поле "материал" - выбрали там из списка, и далее задали цену, QTY и прочие доп. атрибуты коих можно наплодить уже потом? Чем то смахивает на опенкартовскую систему
Тут еще проблема с добавлением опций товара "налету". Так как при добавлении товара еще не известны все значения всех характеристик, а значения опций берутся оттуда =). Думал не делать дополнительные(дублирующие) значения, а брать из уже известных, то есть у товара всеравно будет 10 размеров разных, к примеру, и все они будут записаны в EAV сводную табличку.
Говорите не придумать? =)) А что есть все опции зафигачить JSON форматом в дополнительное поле таблицы с сущностями товара =)) Были и такие советы =)
alex-1917, Ну так и как там реализована эта система не поведуете с высоты вашего опыта? Пока по теме ничего одно сравнение органов причинных. Подскажите уж простым смертным с их "сельпо" как им построить то варианты/опции итд товаров то?
alex-1917, во-первых я не понимаю какая вам разница, кто и что продает. Почему вместо ответа на вопрос вы пытаетесь все умничать. Мы сейчас НЕ разговариваем о рентабельности бизнеса. Во-вторых ювелирная продукция имеет свои ниши, в некоторых может быть не более 5000 товаров просто чисто физически нету производителей по стране для большего обьема. В-третьих пример я привожу именно на ювелирке, потому что сейчас магазин работает уже 4 года и продает ювелирную продукцию, причем имеет склад, закупку, и галерею в Москве, + есть собственное производство, а вы куда-то смотрите в теорию там про открытия магазинов по типу sokolov, тот же bronnitsy. Если у вас есть магазин на 50 000 + товаров и вы купаетесь в деньгах - рад за вас, но ответа на вопрос пока никто дать не может, хотя умничают все и не по теме. Неужели это прям так сложно реализовать.
Как пример https://www.bronnitsy.com/catalog/i/koltso-obrucha... - тут видно при смене размера меняется артикул + цена (не на всех размерах), т.е как минимум эти характеристики как-то связаны в базе и привязаны к сущности. Это просто как пример, по идее, мало ли что на другом типе товара должно меняться. Например, у тех же цепей. Пример еще https://www.bronnitsy.com/catalog/i/braslet-ruchno... - меняется размер - цена - перечеркнутая цена - артикул. То есть это все как будето бы где-то записанная комбинация, запрос при смене цены идет аджаксом с параметрами в контроллер ['action'=>'price', 'attribute_id'=>133131] типо такого. Но по закону сохранения энергии =) в случае с мускулом и приведению к правильным видам, размеры не дожны дублироваться где-то еще в таблицах. Скорее всего товар имеет просто набор размеров, но с другими разными параметрами. И судя по всему сделано это у них на битриксе
alex-1917, Яж про то и спрашиваю, как это реализовать, эти опции или варианты товаров - называйте как хотите, где будет любой набор значений, которые можно комбинировать между собой и выставлять цену + привязка к товару. 20000-50000 тут человек выше предлагал, забивая в базу товары с одинаковым названием и разными размерами. С этим согласен - не камильфо. Стандартный EAV позволяет сделать не ограниченое кол-во характеристик их типов и значений, но как опции такого рода из них сделать хз. Не доходит до меня именно логика этого всего. Конечно товар - сущность одна с одним названием и урлом, остальное только опции.
Сергей Герасимов, даже если все упростить, у некоторых товаров нет размеров, не все товары кольца =). Есть еще цепи, например, у цепей есть плетение - вариант влияющий на цену и длинна цепочки. Вариативность опций как факт нужна всеравно, пускай даже не все товары будут иметь опции
Сергей Герасимов, Кольцо с бриллиантом, кольцо с сапфиром с точки зрения покупателя это все одно кольцо, одна сущность один УРЛ, но с разными камнями. Так как оно даже выглядит одинаково yf 80% ибо оправа одна + оправа может быть изготовлена из белого золота, серебра, желтого золота (логично догадаться что от этого будет разная цена). При этом кольцо будет находится в разных категориях одновременно "кольца с белым золотом", "кольца с желтым золотом" итп. Представляете как удобно человек кликнул 1 раз на категорию, выбрал кольцо, попал в карточку и вдруг расхотел желтое золото и в зял дороже с белым, так как увидел что оно красивее. В дополнение к этому покупатель хочет выбрать кольцо с размером для своих пальцев. А вообще в идеале если такая комбинация характеристик существует, неплохо покупателю еще и показать картинку, как будет выглядеть кольцо с бриллиантом или опалом в белозолотой оправе. И покупатель не хочет кликать дальше по каталогу перебирая названия вида Кольцо %название%, размер %значение%, белое золото
Посмотрите в сторону https://www.kristall-shop.ru/eshop/card/0005cacc41... как минимум есть размер. Почитайте книги сами. За 4 года успешной работы в Москве мы успели прекрасно изучить поведение покупателей в данной теме. Отвечайте пожалуйста по существу.
Yan-s, я вот сам больше склоняюсь именно к определенному алгоритму, это будет и универсальнее и без лишних запросов в бд, так как на данный момент используется EAV, не хочу нагружать базу лишними запросами, ведь на странице помимо фильтров и прочего могут быть еще дополнительные слои со своими запросами. Кстати есть ли на эту тему какие либо шифраторы и дешифраторы? То есть получил строку, зашифровал, и в любой момент расшифровал в исходный вид? Как мне еще кажется можно обойтись даже без редиректов 301. Это тоже важный момент, не желательно их появление в процессе выдачи странички
Алексей Уколов, Спасибо большое за помощь, действительно, в принципе текущая посещаемость около 1000 в сутки, по идее не должны все быстро забить фильтрами.
D3lphi, Дело в том что сайт работает уже 4 года и судя по метрике и гугл аналитике, с фильтров идет 5-15% трафика (и это еще без хорошей оптимизации страничек) Я понимаю ваше возмущение(мне самому проще сделать все стандартно и ниип...ца), но все это основано на реальных фактах. По этому появилась мысль как бы этот процент увеличить. Так как есть реальный результат. Не ругайтесь =) Спасибо за помощь =)
D3lphi, То есть урлы "навечно" не сохранять ... Конечно это логично. Но тут теряется тогда весь смысл сия действия, ссылки нужны для индексации, нужны для трафика, ссылка в поисковике будет хранится N времени. Удалив ее мы получим 404 страничку. Из поиска она вылетит. Трафика не даст. А вдруг она была хорошая и давала много трафика (поисковики не предсказуемые, порой). А наш автобот сайта ее взял и удалил, посчитал ее старой. Конечно с другой стороны ссылка может стать не ликвидной сама по себе (допустим был размер у товарной пачки, а через год его не стало как и части товаров по данному фильтру) и в итоге по данной ссылке вылезет что-то вроде "ничего не найдено". Но в такой ситуевине, я тут подумал, что можно прикрепить к ссылке, результат фильтрации в виде plain/array/json?? списка айдишников товаров. Тогда результат выдаст хоть какой-то но результат (простите за тафтологию)
Алексей Уколов, D3lphi, Простите за мой тупизм =). Про базу я понял. Остался вопрос про миллиарды такого рода записей в ней =) даже на текущем этапе с 5000 товаров и 100000+ значений характеристик. Без базы значит никак? Можно ли сделать это каким либо алгоритмом шифрования и дешифрования "налету"?
diamond, Все верно, по крайней мере в базе собралось уже больше 100000 значение характеристик. А смысл простой, цена проекта растет с такими урлами - это первое, а второе, ну очень хочется такие урлы =) это же супер компактно, минималистично, чем длиннющая строка в браузере, которая зачастую даже не индексируется поисковиком, у тут будет индекс, это 5-15% доп. потенциальных покупателей =)
3 таблицы: ресурс (сущность),
одна сводная (ресурс_ид, аттрибут_ид, значение текст поле) +
характеристики (тип(select,checkbox), название, возможные значения списком с разделителями
есть еще группы характеристик которые привязаны к шаблону (например товар/страница) что угодно - набор полей вида select/text и тд можно любые делать и в любом кол-ве. При том что сделано это просто дико универсально. Текущий шоп на модиксе имеет варианты размеров и цены, но это костылем сделано Может по этому отталкиваюсь от этой структуры начальной базы. Но это просто вариант. Сейчас фреймворк, сделать можно уже как угодно, это огромный плюс.