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

_
На сайте с 24.03.2008
Offline
357
9524

Собственно я знаю, как оно сейчас обстоит дело.

В деталях разбираюсь во внутренней кухне итп.

Однако. Если предположить, что "движок" магазина направлен на продажи в интернете,

а не на ведение склада и отчетности, переписку, печать бланков итп (это всё делает локальная

система отделенная от него), то зачем в нём необходим сервер баз данных :) ?

Собственно вопрос навеян попыткой использовать т.н. "современные флагманские движки" :),

и отказом от них в сторону целиком статического проекта. Пока обкатываю, но по ощущениям,

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

используют "динамическую генерацию страниц", "базы данных с 100500 таблицами" и прочее ?

Нет, больше я не храню заказы - они высылаются по email и обрабатываются локальной системой.

(на всякий случай копия хранится в виде файлов в дирректории с заказами)

Нет, я больше не храню пользователей - это ни им, ни мне не нужно, пользователь вводит своё

имя, email и телефон. Да, он мог бы вводить email и пароль, но ему это сложнее,

практика показывает, что проще не помнить пароля... часто его запрашивают.

Будет очень надо - смогу хранить в файлах. Индексация пользователям не нужна.

Нет, я больше не храню остатки по складу, они в другом приложении ведутся.

Нет, я больше не буду показывать "нет товара", я буду предлагать таким клиентам другой товар,

или продавать их конкурентам.

Нет, мой магазин теперь не переписывается с пользователями - это дело рук менеджера,

либо опять-таки локальной системы.

Нет, теперь никто не заводит товар руками(и не косячит), он выгружается автоматом из той-самой локальной системы.

Нет, корзин я тоже больше не храню, для этого есть local-storage.

A1
На сайте с 30.06.2016
Offline
22
#1

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

mendel
На сайте с 06.03.2008
Offline
183
#2

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

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

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

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

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

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

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

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

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

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

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

Минусы:

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

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

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

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

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

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

Шутку любишь над Фомой, так люби и над собой. (с) народ. Бесплатные списки читабельных(!) свободных доменов (http://burzhu.net/showthread.php?t=2976) (5L.com) Сайты, All inclusive. 5* (/ru/forum/962215)
C
На сайте с 04.02.2005
Offline
246
#3

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

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

M
На сайте с 04.10.2011
Offline
90
#4
mendel:
То что вы ее храните в файлах не отменяет того что это база данных.

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

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

Сдается, обращаться скайп avdesk-it-kmm Верстка, кодинг - контакты в профиле... VPS от 5€ (https://gmhost.com.ua/?partner=10255)
mendel
На сайте с 06.03.2008
Offline
183
#5
Chukcha:
привязка к категориям, производителям, всякие вы просматривали, рекомендуемые, акции, последние, тоже все в "удаленной" базе?
А параметры доставки, оплаты?

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

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

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

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

_
На сайте с 24.03.2008
Offline
357
#6
mendel:

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

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

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

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

mendel:

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

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

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

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

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

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

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

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

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

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

C
На сайте с 04.02.2005
Offline
246
#7
mendel:
явно в локалстор или куках,

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

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

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

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

_SP_:
Не могу понять, какого рода сложное динамическое содержимое могло бы быть
полезно на страницах интернет-магазина.

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

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

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

_
На сайте с 24.03.2008
Offline
357
#8
mendel:

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

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

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

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

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

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

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

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

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

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

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

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

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

[Удален]
#9
_SP_:
Эээ... а нафига интернет-магазину БД :) ?

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

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

_
На сайте с 24.03.2008
Offline
357
#10
Объем продаж,

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

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

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

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


доступность на складе,

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

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


мултиязык

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

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

Из той-же ERP.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий