У меня проблема в том, что у таких товаров много одинаковых свойств, такие как title, seo и т.д.. Да даже фотки одинаковые будут.. Таким образом надо все же как то к товару умудриться присобачить это.. А на счет галок для отметки свойств интересно, так наверное и сделаю
Я про то и говорю, он будет покупать по сути торговое предложение же верно? Вообщем у меня сейчас такая схема: есть товары, они привязаны к какой то группе, группа имеет несколько атрибутов. Также есть торговые предложения, которые привязаны к товару и на основе группы генерируется форма с атрибутами этой группы.. Но есть 2 проблемы - 1) эта схе а не предусматривает товары без атрибутов, так как тогда как раз придётся добавлять в корзину помимо торгового предложения ещё и сам товар, что геморойно.. 2) значения атрибутов хранится в json поле в таблице с предложениями, так что нормальным путём нельзя сделать фильтр по ним. Что скажете?
Спасибо, это уже ближе, такой вариант тоже рассматривал, НО! Как быть с корзиной и заказами? Добавлять в них ид торгового предложение, и товара получается? Или есть ещё варианты?
Ну в том то и вопрос как организовать товары и их схожести! Вы можете в контексте mysql пояснить как хранить это все? Пока вы только сказали, что схожий товар должен иметь артикул, что и так понятно ;)
Я это все уже изучал, там масса проблем на выходе получается.. Допустим даже при выводе свойств цену апдейтить каким то образом надо, делать это через аякс вообще не вариант, значит надо соствить матрицу, а потом искать пересечения и что то в этом роде. Также с выборкой получаются очень большие заморочки
Я хочу сделать 1 товар, а к нему уже привязывать его разновидности. Вопрос даже не в этом, а в том, как хранить динамически эти атрибуты и делать выборку! А так то получается так как вы сказали только объединяющим ключом у меня как раз будет ид товара
Как я выставлю цену товару, если у него будет много цен? Цены зависят от характеристик.. Тут по любому отдельная таблица нужна, в которой будет цена конкретной комбинации товара, кол-во и тд
"На секундочку, как вы себе представляете описание бизнес логики в модели того же Laravel или Symfony" а что вы здесь имели ввиду? Интересно, как вы представляете описание бизнес логики не в моделей? Мне что то подсказывает что для вас модель = orm..
Лол! Модель - это часть где обрабатываются данные и с ними выполненияются какие то действия.. Там и предметная область и бизнес-логика и все вообще.. Это и есть мозги приложения которые могут выполнить бизнес задачу. "Предметная область - это таблицы, связи и отношения между ними." Это просто шикарнейшее определение, которое не только к предметной области не относится, но и к приложению вообщем.. Какие таблицы? При чем они здесь? Согласен про то, что фреймворк все немного искажают.. Я тоже по началу изучал ларавель и для меня модель была связана с таблицами, связями и прочей хренью, по сути моделью не являющейся.
ИМХО, js это как капля в море, которую разумеется безумно мало, чтобы высушить его... Ужасает как много людей плюсует подобные ответы! Вы сами то знаете js? Или освоив какой нибудь react вы считаете себя гуру по js и вообще программированию?
Ну лишним кажется круд никогда не будет.. Я реализовал с помощью backpack crud вполне удобную админку, изменив только типы полей и установив связи.. Можете примеры привести примеры сложных записей, где crud будет неприменим? Его же потом очень просто подпилить и сделать так как нужно разве нет?