Выводы

Если следовать традиции, то здесь следовало бы подвести итог выше рассмотренным технологиям, их преимуществам, недостаткам, рекомендациям по использованию и др. Однако данное сравнение чаще всего производится с точки зрения самих технологий, нежели с точки зрения проблемной ориентации интернет-приложений. Более того, производить сравнение серверных технологий с технологиями на стороне клиента, в общем случае, некорректно, поскольку они отличаются друг от друга на концептуальном уровне. Если говорить о самих программных технологий и их возможностей, то серверные технологии предоставляют разработчику на порядок больше возможностей, чем JavaScript, поскольку они приближаются к полноценным языкам программирования. С другой стороны, в рамках частных задач с помощью JavaScript можно разработать программные решения, которые на порядок превосходят серверные. Поэтому дальше будет произведено параллельное сравнение рассмотренных выше технологий как на общем уровне, так и частном, применительно к конкретной задаче.

Размер базы данных и возможность масштабирования. При использовании JavaScript данные сохраняются в массиве. Я не ставил перед собой задачу определения максимально допустимого размера массива в JavaScript, поэтому привожу мнение стороннего автора ~ 200 - 250kb. Даже если эти данные несколько занижены, то в силу вступают другие ограничения - объем загруженной информации и скорость поиска записей в массиве. Для пользователей выделенного канала разовая загрузка 200 - 250kb может занять несколько секунд или минут, однако передача такого объема по модему может занять несколько десятков минут. Предположим, что средний размер записей равен 50b. Пусть объем базы данных равен 100kb = 102400b, тогда мы сможем создать массив данных c 2000 записями (102400/50=2048). Практика показывает, что компьютер класса PIII-900 достаточно неплохо производит поиск по 2000-3000 записей в массиве.

На размер базы данных будет влиять как структура самой информации, так и используемые программные решения. Мне кажется, что предел базы данных с использованием одного массива JavaScript находится где-то между 3000-5000 записями. Много это или мало? Все зависит ассортимента предлагаемых организацией товаров и услуг и их структуры. Для небольшого магазина такой объем базы данных может быть вполне достаточным, однако для больших каталогов и библиотек может потребоваться база в десятки раз больше данной. В этом случае придётся воспользоваться услугами реляционных баз данных, например MySQL.

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

L_Str='123#Микропроцессор 4040#100|456#Микропроцессор 8088#300';

Мы видим, что название товара "Микропроцессор" повторяется два раза. Заменим данную строку на строку "аа" (с помощью символов можно закодировать больше информации, чем с помощью цифр), тогда наша строка преобразуется так:

L_Str='123#aa 8080#200|456#aa 8088#300';

А строка расшифровки, например, будет такой:

L_Code='aa#Микропроцессор';

Тогда в процессе построения массива объектов из строки данных можно произвести подстановку части названия вместо ее сокращенного обозначения.

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

Если каталог товаров состоит из множества разделов, в которых присутствует один и тот же товар, то можно существенно уменьшить размер базы данных, если сформировать структуру данных с отношением "один ко многим". Уменьшить размер базы данных с помощью данного способа мне удалось на 60% (сравните с предыдущим способом, где было 10%). Можно еще сильнее сжать данные, если комбинировать эти два способа, но чем сложнее техника сжатия, тем больше времени потребуется на дешифровку данных, а браузер пользователя - далеко не самая быстрая программа.

Можно пойти по пути увеличения размера базы данных. Для этого можно разбить большой js-файл на несколько и загружать их в интернет-магазин по мере необходимости. Однако поиск в этом случае будет возможен только по загруженным данным.

Скорость. Скорость работы серверных технологий намного выше скорости работы JavaScript, но из-за больших потерь времени на передачу данных от браузера пользователя к Web-серверу и обратно, неэффективных программных решений на сервере, перегрузке Web-сервера и др., создается впечатление, что это не так. Да, выполнение простых операций, например, проверка правильности заполнения формы или поиск товара в небольшой базе данных, на JavaScript производится быстрее, чем выполнение тех же операций на стороне сервера, однако с увеличением функциональности интернет-магазина данная ситуация изменяется на противоположную. Единственно правильным решением будет использование преимуществ и той, и другой технологии, исходя из поставленных задач.

Функциональность. Здесь может показаться, что серверные технологии намного опережают возможности JavaScript. Это действительно так (простой пример - PHP-библиотеки функций, SQL-запросы и т.д.). Однако есть области, где JavaScript на порядок смотрится лучше любой серверной технологии - оперативное управление и инкрементный поиск. С другой стороны, вопросы администрирования и управления данными эффективно можно решить только с помощью реляционных баз данных.

Простота в изучении и разработке. В общем случае, изучить JavaScript намного легче, чем, например, PHP и MySQL, однако для простых интернет-магазинов, как правило, не требуется больших знаний серверных технологий. С другой стороны, JavaScript используется совместно с HTML, DOM и CSS, что в ряде случаев требует знания тонкостей данных технологий. Мне пришлось столкнуться с этим, работая над оптимизацией вывода данных на JavaScript. Оказалось, что программные алгоритмы, которые приводятся в литературе по этому языку, могут на 30-40% замедлять работу программного кода. При этом ссылки на данные обстоятельства не указываются нигде (хотя в любом руководстве можно легко найти раздел, посвященный оптимизации графики, тогда как web-дизайн - это далеко не весь Интернет).

В качестве заключения ещё раз отмечу, что рассматривать ту или иную технологию как на стороне сервера, так и клиента необходимо в контексте определённых целей и поставленных задач комплексно. Выбирать технологию без учета этого равносильно попытке установить мотор от "Формулы-1" на "Оку". Увеличение скорости, возможно, неплохая мысль сама по себе, но задачи-то у них разные. Идеальный вариант - тот, при котором недостатки одной технологии компенсируются достоинствами другой, в рамках поставленных задач.