В WIT-e мы, конечно, иноходцы.
Своя ERP-система (о ней я писал здесь - Как же обойтись без 1С? ), своя CRM-система, свой М2М для общения с дистрибьюторами («какие еще умные слова и аббревиатуры вы знаетеЭ»).
И, конечно же, ваш подход к WWW должен оставаться в рамках этой трехбуквенной парадигмы.
Все началось с любви к Microsoft, и некоторые ранние версии сайта еще в конце 90-х были сделаны с использованием технологии ASP, а в качестве базы данных использовался обычный файл MS Access. Кстати, провайдеры до сих пор предлагают хостинг на старом добром ASP, спустя 18 лет после его обновления до ASP.NET — вот вам и устаревшие системы во всей красе.
В целом это довольно удобно — поскольку внутренняя база данных тоже написана на MS Access, процедура подготовки данных для сайта была очень простой, никаких ретрансляций из одного формата данных в другой (MySQL например).
Access поддерживает расширение языка SQL в форме «IN».
», который можно добавлять после любых операторов DML: INSERT, UPDATE, DELETE (вот вам еще одно трехбуквенное сокращение).
По мере того, как эта связка разрасталась, она, конечно, начала безбожно тормозить (плюс случившаяся необъяснимым образом блокировка mdb-файла с базой данных, отключившая весь сайт).
Перевод сайта на ASP.NET кардинально проблему не решил, а также пришлось перейти на MS SQL Server в качестве базы, но здесь процесс пошел в другом направлении.
Давайте посмотрим на проблему повышения производительности сайта немного с другой стороны.
(Кстати, мой провайдер 1Gb.ru пишет, что ASP.NET в среднем быстрее стандартной комбинации LAMP (Linux/Apache/MySQL/PHP), что для меня стало открытием.
Но кому здесь можно доверять, как не самому оператор всего этого?) Отказ от ответственности – последующие идеи представляют собой, с одной стороны, некую теоретическую конструкцию, возведенную в абсолют, а значит, зачастую доведенную до абсурда; с другой стороны, конкретная реализация, поэтому нельзя сказать, что автор витает в своих фантазиях и полностью оторван от реальности.
Вопрос 1. Зачем нужна база данных под сайтом? Ну, действительно, вы все восхищаетесь производительностью баз данных в памяти, верно? Так зачем идти далеко, купите себе такой прямо под своим сайтом.
И даже больше.
При первоначальной инициализации загрузите все данные в массивы, доступные на уровне сайта в целом (Объект приложения в ASP.NET, глобальные переменные в PHP и т. д.), и вместо написания запросов к базе данных просто перебирайте эти массивы в цикле.
Для первоначальной загрузки данных подойдет что угодно — та же база данных MS Access или даже текстовые файлы CSV! – операция проводится нечасто и время ее выполнения не играет никакой роли.
Возникают вопросы, но у нас уже есть готовые ответы на них
- Что, если веб-страница выбирает данные из запроса, а не из таблицы? Очень просто — преобразуйте результат запроса в таблицу (на своем внутреннем сервере, при подготовке данных для сайта), а затем следуйте предложенной схеме,
- Эта идея не сработает (или приведет к пустой трате памяти) в следующем типичном случае.
У нас есть каталог интернет-магазина с кучей товаров в каждом подразделе.
Что нам делать — создавать отдельную таблицу (массив в памяти) для каждого подраздела каталога, выбранного простым запросом? Честно говоря, даже в таком крайнем варианте я не вижу больших проблем — просто создайте массив большей/большей размерности, куда поместите результат связывания обеих таблиц — и каталога, и товаров.
Но в случае с нашим сайтом это решается простейшей индексацией такого типа.
В таблицу «Каталог» (массив в памяти веб-сервера!) добавляется 2 столбца — начальный и конечный индекс элемента товара во второй таблице:
а цикл отображения позиций товара в этом разделе каталога идет от MinIndex до MaxIndex. Замечу, что при подготовке таблиц массивов для сайта уже можно задать необходимую сортировку (но только один вариант) - в приведенном выше случае для работы схемы таблица Детали должна быть отсортирована по идентификатору таблицы Каталога, а затем в нужном нам порядке в определенном разделе каталога.
Точно так же, как данные передаются из базы данных под сайтом в структуру данных самого сайта, при генерации веб-страницы необходимые ей данные могут быть размещены в самой ее структуре — то есть в массивах JavaScript. И никакого AJAX, асинхронности, обработки ошибок связи и т. д. Это то, что мы сделали на нашем сайте на страницах, содержащих всякие конфигураторы.
Кстати, в отличие от файлов баз данных, массивы в памяти веб-сервера (и веб-браузера тоже, хотя и с оговорками) занимают размер, примерно равный их двоичному представлению, а пустая база данных с единственной таблицей в ней уже составляет многие сотни килобайт. Вопрос 2. Зачем вообще нужно использовать скрипты на веб-сервере? Привожу фрагмент кода в несколько строк, намеренно упрощенный и на самом безумном из языков программирования - VBA (кроме 1С).
Код делает следующее: пропускает страницу через некогда очень популярный браузер одной известной компании и сохраняет результат работы серверного скрипта в виде чистого HTML. Вы, наверное, уже догадались, что будет предложено дальше? Совершенно верно — вполне возможно сделать сайт чисто HTML, как в старые 90-е.Set IE = CreateObject("InternetExplorer.Application") IE.Navigate "wit.ru" While IE.ReadyState < READYSTATE_COMPLETE Wend Set str = IE.Document.DocumentElement HTML = str.innerhtml
(Опять с 1GB.ru: «IIS очень быстро и эффективно обрабатывает запросы к статическим файлам») В этом случае вам, возможно, придется беспокоиться о перекодировании адресов, таких как wit.ru/card.aspxЭid=23&prodid=1022985 в статические адреса веб-страниц — это тоже известная технология настройки веб-сервера, изначально придуманная для обмана поисковых систем и веб-оптимизации.
Здесь, вероятно, необходимо сформулировать основной принцип, из которого вытекают все остальные.
Чем больше времени и ресурсов мы потратим на подготовку данных для сайта, тем легче ему будет их отобразить и тем быстрее он сможет это сделать.
В этом случае наш бэкенд может работать вообще в непрерывном режиме, выплескивая на сайт готовые данные с той частотой, которая нам нужна.
И такой подход будет работать во всех случаях, кроме, конечно, отчетов фондового рынка или каких-нибудь витрин Amazon или Alibaba, где данные меняются каждую секунду.
Заключение
Я осознаю, что проблемы в статье слишком острые, а предлагаемое решение слишком нестандартное.Рискну предположить (это вообще не моя тема), что такой подход мог бы работать для всяких встраиваемых систем, где в противном случае на слабом с вычислительной точки зрения устройстве придётся размещать мини-движок БД и скриптовый процессор вместо простейшего веб-сервера (ценой большего потребления памяти - оперативной и постоянной памяти).
Теги: #Разработка сайтов #HTML #ASP #ASP #Pure HTML #Static WEB
-
Почему Люди Используют Photoshop?
19 Oct, 24 -
Raspberry Pi Без Проводов
19 Oct, 24
