Эээ... а нафига интернет-магазину БД :) ?

В чем суть сообщения?

У вас есть база данных товаров, категорий, свойств и т.п.

То что вы ее храните в файлах не отменяет того что это база данных.

Итого реально у вас два разделения:

1а) Ваша база храниться на хостинге, и ваш движок генерирует из нее страницы.

1б) Ваша база находится в другом месте, движок магазина находится там-же, а на хостинге хранятся только статические страницы являющиеся грубо говоря "кешем" вашего магазина.

Здесь не важно где эта база заполняется и в каком формате она хранится. Важно что она есть.

Второе разделение:

2а) Использовать в качестве базы данных реляционные СУБД (в первом приближении сюда можно отнести и noSQL)

2б) Сделать свой велосипед на файлах.

Для простой витрины за которую всё делает "отдельная система с полноценной СУБД) вполне может хватить и своего файлового велосипеда.

Да, это усложнение, но возможно для какой-то задачи оно у вас и оправдано.

Минусы:

Собственный велосипед для файлов который нужно поддерживать,

Ограничение роста сложности витрины и необходимость уносить почти всю логику в отдельный сервис.

Плюсы вы можете написать сами.

У меня был кейс где такой путь казался уместным. Был основной сайт с полноценной системой учета всего, и был связанный с ним файлообменник.

Функционал ФО был минимальный, да добавить файл мог любой, но основное заливалось через отдельное АПИ, в виде уже готовых файликов и файликов-описаний. Через пару лет таки вернулись к единообразию с базой и т.п.

Сложность поддержки разных кодовых баз дорого.

Т.е. привязка к категориям, производителям, всякие вы просматривали, рекомендуемые, акции, последние, тоже все в "удаленной" базе?

А параметры доставки, оплаты?

Абсолютно согласен с Вами коллега.

Более того, именно с этого и начинались современные быстрые и реально работающие СУБД

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

Параметры доставки/оплаты вполне могут быть настолько простыми что могут быть и захардкожены или уточняться уже менеджером в телефонном режиме.

Сделать можно всё, но это уж очень пахнет Fat Stupid Ugly Controllers.

Оно конечно не совсем оно, или даже совсем не оно, но сам подход очень сильно похож.

Да какое-ж это усложнение, это упрощение.

Сделать экспорт из "отдельной системы с полноценной СУБД" оказалось в 100 раз проще, чем разобраться и заставить работать то, что "наворотили" современные разработчики. Т.е. это всё реально быстрее оказалось, даже во внедрении.

Не у всех есть ERP, но если у вас его нет, то вы вряд-ли "жилец" с тем эрзацем, что предлагает интернет-магазин.

Да, согласен, отсутствие необходимости в БД скорее следствие отказа от

динамического содержимого. Вы правильно написали - пользователю отдается "кеш",

только в отличии от систем с кешем, тут всё гораздо прозрачнее и беспроблемнее,

и время генерации этого кеша мало, в результате при относительно дешевом

дисковом пространстве для среднего размера проектов его можно один раз сгенерировать

в момент апдейта и потом спокойно отдавать юзерам.

Было бы, наверное правильно, рассматривать иной вопрос.

Не могу понять, какого рода сложное динамическое содержимое могло бы быть

полезно на страницах интернет-магазина. Исключая корзину.

id? или полностью статику??

Хранилище таких вещей не имеет значения. (куки, сессия, лс)

localstorage - и как отдать оттуда серверу Только запросом, ну.. можно конечно подтянуть аяксом.

---------- Добавлено 26.12.2016 в 17:09 ----------

Объем продаж, доступность на складе, мултиязык

А все что вы рассказали - убрали учет, и но поместили его в другую базу, а ваш - надстройка, ведь все равно вы берете данные оттуда.

Динамические они или нет - не существенно

Да нет, тут подход обратный.

Мы отказываемся от Stupid функционала в интернет-магазине.

Насовсем. Он больше не делает ничего из того, что делают современные интернет-магазины.

Он только показывает товар и собирает заказы.

А всю прочую шнягу делает другой специализированный софт, который умеет её делать хорошо.

Т.е. статистику посещений собирают гугл, с яндексом и adwords, письма рассылает менеджер

из тикет-системы получающей тикеты в виде заказов, итд итп. Склад ведется в своей программе.

А магазин получается не Fat, а очень-очень Thin. В нём нет лишнего.

Он очень тонкий и очень простой.

Яж не против обширной функциональности, но посмотрев как она на сегодня реализована

пришел к выводу, что "из коробки" она не удовлетворяет моим требованиям, а её допил

вполне сопоставим с созданием с нуля на прозрачной простой системе.

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

P.S. это не стёб, всё абсолютно серьёзно

Вы хотите показывать клиенту и конкурентам то, сколько продали товару ?

И показывать правду в реалтайме ? Я нет.

В реалтайме у меня это есть условно в ERP.

И гораздо лучше сделано чем в любом интернет-магазине.

Всегда доступно.

Если нет - продам ваш заказ конкурентам :)

Вообще 0 проблем.

URL-ы для английского другие. По ним будет генерится английская версия.

Из той-же ERP.

Я не пойму что заставляет людей хранить в БД что-то для интернет-магазина.

И каждый раз, генерировать страницы для каждого пользователя.

Логика от меня ускользает такого решения.

Тут речь о том, что можно очень четко разделить мухи от котлет.

Но почему-то "в среднем" этого не сделано. Не могу понять почему.

Т.е. понятно, зачем это нужно тем, кто эти магазины и услуги по их

развертыванию продает. Непонятно зачем владельцам это все нужно

и как это всё удалось им навязать.

---------- Добавлено 26.12.2016 в 18:22 ----------

Да про движок я знал уже лет 10, может больше.

Первые самописные шаблонизаторы которые я написал были черт знает когда сделаны,

отлично себя зарекомендовали, потом появились всякие смарти, твиги итп.

Я поражаюсь, что нет тонких интернет-магазинов, все какие-то монстры.

Неужели выигрыши неочевидны ?