Схема Базы Данных интернет магазина - страница 2 - Флейм

Сколько товара на складе - понятно (shop_product_storage), а сколько заказал покупатель?

По идее надо вычитать уже после оплаты. Хотя в любом случае товар на какое-то время блокируется. Т.е. товар может быть и не куплен, но отправлен курьером. В итоге считать товар полностью автоматически не получается. Тут уже менеджер возвращает на склад не проданые товары.

И ещё кое что...
Меня тут посетила мысль привязать склады к городу.
Щас какое-то время всё будет расчитываться, что все товары лежат на нескольких складах в городе Москва(например).

И у нас есть курьерская доставка. Цена которой расчитывается от удалённости от Москвы.
Но что если товары лежат на складе Санкт-Петербурга?
Как в этом случае считать товар и выполнять/расчитывать доставку?

По идее тут тогда всё становится на порядок сложнее...
Во первых нужно выводить только товары которые есть на складах города X.
Во вторых опрашивать пользователя где он живёт.

Это я сделаю потом, но думать об этом нужно уже щас...

Давно хотел и вот мне тоже представилась возможность написать небольшой магазинчик. Пока накидал такую схемку:



У заказчика впринципе товаров немного, но хотелось бы что нибудь более менее универсальное, чтобы можно было использовать в других проектах хотя-бы. Что скажете господа разработчики?

Я бы убрал productstock: думаю, что ничего страшного в добавлении лишних 2 полей в products. Взамен добавил бы productset для продажи комплектами (заказчик не хочет самописного компонента в силу дороговизны и просит доработать VM, уж не знаю, где больше работы).
P.S. А что со скидками и всякими там привилегиями? Короче, что бы ни задумал, все равно получится VM или JS.

Когда есть готовая наработка и мне работать приятнее и заказчику дешевле получится чем пилить готовые магазы.  Так уж получилось что мой загазчик и есть мой друг в одном лице и у него уже есть магаз, который дико глючит. Так что он готов заплатить за индивидуальное решение. Вместо productsets у меня поле product_components предусмотрено. Туда как раз дочернии товары или комплекты буду записывать.

А что со скидками и всякими там привилегиями? Короче, что бы не задумал, все равно получится VM или JS.

В том то и дело что ничего лишнего, что напихано в крупные магазы вроде VM или JS не нужно. Магаз должен быть легкий, обновляемый и расширяемый. В отдельном функционале для скидок пока нет необходимости. Пока будут поля которые будут менять цену( возможно дискаунт будет реализован как скрытое доп. поле) VM, JS и прочее не будет уже хотя бы потому что небудет этого ужасного многоступенчатого заказа.

Про productstock впринципе я с вами согласен, для небольшого магаза он нафик не нужен. С другой стороны, вдруг потом понадобится разделить товар по складам, лишняя таблица тоже вобщемто ничего страшного.

По ходу дела, та схема что была в начале претерпела сильные изменения.
Но магазин готов. Правда ещё по нему работ очень много...
http://185.5.251.41:7500/

Хотя бы заполнение...

Но магазин готов.

Жму "добавить в корзину", ноль реакции...

Если сами писали, зачем инлайн скрипты и стили? и jQuery древняя совсем?

http://185.5.251.41:7500/

не понятно за чем блоги, лучше имхо зависимые материалы, тогда и перелинковка будет и можно информацию размещать
@fsv
там фреймворк скриптовый

Жму "добавить в корзину", ноль реакции...

Если сами писали, зачем инлайн скрипты и стили? и jQuery древняя совсем?

Потому что доступен один товар, для покупки... Остальные - нет в наличии. Суть состоит в том что многое банально не заполнено.
И вообще проект заморожен из-за отсутствия денег на развитие. Я вернусь к нему наверное только через 2 недели.

не понятно за чем блоги, лучше имхо зависимые материалы, тогда и перелинковка будет и можно информацию размещать

Магазин + Блог потому что будет... Специально сделал систему комментариев для этого. Одностраничные сайты мало того что сложнее в несколько раз делать. Дак ещё и с SEO будут проблемы. Но зато когда их решишь получишь много опыта, который везде пригодится.