Непосредственно получающая доступ база данных сервера через Ajax (без PHP или некоторого другого промежуточного звена)
С мощными платформами как jQuery это, кажется, возможно создать логику целого приложения на стороне клиента. Это очень походит на создание клиентского приложения как собственная программа.
Теперь предположите это клиентское приложение потребности получить доступ к удаленной базе данных. Обычное решение, кажется, включает уровни Ajax/PHP/MySQL.
Мне кажется, что уровень PHP больше не необходим; вся логика и UI заботятся о приложением браузера.
Вопрос затем: не Должен там существовать (надо надеяться, устойчивый и безопасный) сервер базы данных, который просто берет Запрос HTTP и возвращает результат XML? Этот результат может затем быть легко проанализирован, например, jQuery на стороне клиента.
Я, может казаться, не нахожу базу данных или платформу вдоль этих строк. Какие-либо идеи?
3 ответа
Вы имеете в виду, есть ли база данных, которая изначально поддерживает протокол HTTP? Что ж, есть такие. У вас есть MonetDB / XQuery ( http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/ ) и базы данных NoSQL, такие как CouchDB ( http://couchdb.apache.org/ ). У вас также есть это в более традиционных rdbms-es, таких как Oracle (Oracle Application Express полагается на встроенный HTTP-сервер, также известный как служба APEX http://www.oracle.com/technology/products/database/application_express/ index.html ) и MS SQL (объект схемы службы, например http://msdn.microsoft.com/en-us/library/ms190332.aspx и представления XML, см. http://msdn.microsoft.com/en-us/library/aa286527.aspx )
Но на самом деле - вы должны спросить, действительно ли это так полезно .
Я имею в виду, что всегда будет один компонент, который обрабатывает HTTP. У вас может возникнуть ощущение, что нужно удалить слой веб-сервера / php, потому что вы чувствуете, что он лишний и находится между приложением и базой данных. Но на самом деле решения, которые я только что упомянул, не так уж и отличаются -они помечаются поверх одного и того же программного обеспечения, но данные все равно должны проходить через этот дополнительный уровень.
И вы можете задаться вопросом, действительно ли это выгодно иметь все в одном куске: с отдельным веб-сервером вы можете масштабировать уровень веб-сервера независимо от сервера базы данных. Или вы можете масштабировать уровень базы данных независимо от уровня веб-сервера. Если это все одно программное обеспечение, вы не сможете.
По сути, встраивая http-сервер в базу данных, вы обременяете сервер db задачей, которая потребляет ресурсы, которые могли быть использованы для других задач db. Теперь подумайте о распространенном случае, когда вы заплатили за лицензию на процессор для своей базы данных. Вы действительно хотели бы потратить эту лицензию на то, чтобы db обрабатывал HTTP-запросы, когда вы могли бы сделать именно это с помощью бесплатного веб-сервера, такого как apache? Даже если вы используете бесплатный программный продукт базы данных, во многих случаях сервер базы данных является узким местом. Вы действительно хотите поставить на него больше задач, встроив в него HTTP-сервер?
Есть еще одна причина, по которой я считаю, что это не очень хорошая идея. Вы упомянули XML как формат обмена данными. Гуди. Но что, если вам нужен JSON? Или ЯМЛ? Или, может быть, простой CSV? Языки сценариев веб-серверов, такие как PHP, ASP.NET, Perl и даже Java, имеют очень хорошие библиотеки для решения этих задач. Типичные языки хранимых процедур баз данных этого не делают. Конечно, вы можете пойти дальше и сказать: черт возьми, почему бы не создать, скажем, Java или.NET в базу данных, но это снова переворачивает проблему - задача базы данных - хранить и извлекать данные, а также заботиться о данных во время их хранения. Обработка данных для представления их приложению не является частью этого. Если вы сделаете это частью работы базы данных, вы лишитесь важного источника гибкости и масштабируемости системы в целом. Вы можете подумать, что это меньше накладных расходов, потому что нужно думать на один компонент меньше (например, веб-сервер / язык сценариев), но на самом деле он все еще там, он просто скрывается внутри программного обеспечения вашей базы данных и поглощает ресурсы, которые могли быть использованы для хранение и получение данных, анализ запросов и т. д.
Ну, самой раздражающей частью будет аутентификация.
Поскольку код выполняется полностью на стороне клиента, клиент знает все аутентификационные данные для доступа к серверу базы данных.
Это довольно... эээ... небезопасно. Возможно, именно поэтому не так много людей разработали сервер с прямым доступом.
Если вы действительно хотите свести PHP/Server-Side scripting к минимуму, сделайте достаточно надежный PHP-прокси, который правильно экранирует все данные. Храните детали конфигурации в отдельном защищенном ini-файле или даже в файле php.ini, и после этого вы можете практически не обращать внимания на серверные сценарии.
Я полагаю, что это можно сделать, но PHP более удобен для манипулирования наборами результатов. Кроме того, традиционный подход обеспечивает дополнительный уровень безопасности, так что машины в дикой природе не имеют прямого доступа к базе данных, и можно использовать все обычные средства безопасности и контроля доступа веб-сервера.