Коллеги, добро времени суток! Есть у меня один интересный вопрос - насколько у Opencart хорошая структура базы данных? На мой взгляд она весьма хороша и стройна. Но вдруг я ошибаюсь!? Есть идея взять Opencart за основу. Знаю что есть хороший модуль обмена с 1с. Это очень привлекает. В основном сам движок для этого и будет использоваться. А также как приложение для изменения настроек в БД. На основе имеющейся БД уже будет строится другое приложение - RESTful server + Angular (Витрина) + Angular (Админка для контентов) + и так далее.
На вкус и цвет Мне вот многое нравится и переходить не собираюсь пока. Кто то сидит на Laravel и будет утверждать, что у опенкарта структура стара (и будет прав). Но по мне, все очень удобно и прозрачно. Есть моменты какие подправить, но это мелочи.
Согласен! Среди CMS, Opencart показался мне самым понятным и гибким. А учитывая, что движок бесплатный, считаю его топовым. Хотя может быть это просто первая любовь . Однако, с точки зрения технологичности и современности, Opencart конечно же проигрывает Laravel. Стоит ли говорить про такие технологии как ASP.Net, Spring и т.п. Но вообще не факт, что реализация магазина на фреймворке в итоге будет правильной. Поэтому я решил озадачиться гибридным вариантом и в первую очередь меня интересует база данных, так это самое важное и ошибки в её архитектуре непростительны.
Да, нормализация Сейчас таблица денормализовна - все в одном Нужно только ВСЕ что касается заказа + доп таблицы, по примеру order_product order_shipping order_payment order_custom_field Мы о базе или о функционале? Я говорю о структуре базы Чего не хватает VIEW Trigger Procedure Но это скорей всего вопрос к ПРОСТОТЕ и общедоступности ОС мог подняться на самых дешевых хостингах Что касается программной структуры По сути - это не ООП - а процедурный стиль с применением ООП - это также объяснимо Не знаю что такое Spring.. многое зависит также от выбора хранилища - ОС запилен под mySql Для других SQL серверов нужно много переделывать
Ну видимо это связано с тем, что доставка и оплата подключаются модулями. Может имеет смысл создать отдельную таблицу по методам оплаты и доставки. При подключении модуля создавать запись и выдавать id, который уже прописывать в order_shipping. Тогда вроде и таблица order_total не особо нужна будет. Я вообще плохо понимаю зачем она. MySQL вполне устраивает в данной ситуации. Правда придется uuid хранить как строку, но не критично, ибо они в 1С будут формироваться.
Тут такая штука Продумано все хорошо Вот смотрите Номер заказа ЯЗыК заказа Магазин заказа Сумма заказа Валюта заказа Далее таблица order_payment order_shipping Почему оно в таблице заказов? А потому что лень Было Даниелю и связь там 1строка к одной строке order_total Тут явно требуется таблица здесь к одному заказу несколько строк order_product order_option
