Прямой доступ к базе данных сервера через Ajax (без PHP или какого-либо другого промежуточного звена) - PullRequest
7 голосов
/ 13 февраля 2010

С такими мощными средами, как jQuery, представляется возможным построить целую логику приложения на стороне клиента. Это очень похоже на создание клиентского приложения как нативной программы.

Теперь предположим, что этому клиентскому приложению необходим доступ к удаленной базе данных. Обычное решение, похоже, включает в себя слои Ajax / PHP / MySQL.

Мне кажется, что слой PHP больше не нужен; вся логика и пользовательский интерфейс позаботятся о приложении браузера.

Тогда возникает вопрос: не существует ли (надеюсь, надежного и безопасного) сервера базы данных, который просто принимает HTTP-запрос и возвращает XML-результат? Этот результат затем может быть легко проанализирован, например, jQuery на стороне клиента.

Я не могу найти базу данных или фреймворк в этом направлении. Есть идеи?

Ответы [ 3 ]

12 голосов
/ 13 февраля 2010

Вы имеете в виду, есть ли база данных, которая изначально поддерживает протокол HTTP? Ну, есть некоторые. У вас есть MonetDB / XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/), и базы данных NoSQL, такие как CouchDB (http://couchdb.apache.org/).). Вы также можете использовать его в более традиционных rdbms-системах, таких как Oracle (Oracle Application Express использует встроенный HTTP-сервер, aka служба 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. Вы действительно хотели бы потратить эту лицензию на то, чтобы db обрабатывал HTTP-запросы, когда вы могли бы сделать именно это с помощью бесплатного веб-сервера, такого как apache? Даже если вы используете бесплатный программный продукт базы данных, во многих случаях сервер базы данных является узким местом. Вы действительно хотите поставить больше задач на свой планшет, встроив в него HTTP-сервер?

Есть еще одна причина, почему я думаю, что это не очень хорошая идея. Вы упомянули XML как формат обмена данными. Гуди. Но что, если вы хотите JSON? Или ЯМЛ? Или, может быть, простой CSV? Языки сценариев веб-сервера, такие как PHP, ASP.NET, Perl и даже Java, имеют очень хорошие библиотеки для решения этих задач. Типичные базы данных хранимых процедур языков нет. Конечно, вы можете сделать еще один шаг вперед и сказать, черт возьми, почему бы не встроить, скажем, Java или .NET в базу данных, но это переворачивает проблему с ног на голову - задача базы данных - хранить и извлекать данные, а также забота о данных, пока они хранятся. Обработка данных для представления их в приложение не является частью этого. Если вы сделаете это частью работы БД, чтобы позаботиться об этом, вы заберете важный источник гибкости и масштабируемости системы в целом. Вы можете почувствовать, что это меньше затрат, потому что есть на один компонент меньше (т. Е. Веб-сервер / язык сценариев) для размышлений, но в действительности он все еще здесь, он просто прячется в программном обеспечении вашей базы данных и высасывает ресурсы, которые могли быть использованы для хранение и извлечение данных, анализ запросов и т. д.

8 голосов
/ 13 февраля 2010

Ну, надоедливой частью будет аутентификация.

Поскольку код выполняется полностью на стороне клиента, клиенту известны все детали аутентификации для доступа к серверу базы данных.

Это довольно .. ошибочно ... небезопасно. Наверное, поэтому не так много людей разработали сервер прямого доступа.

Если вы действительно хотите свести к минимуму использование сценариев на стороне PHP / сервера, создайте довольно надежный прокси-сервер PHP, чтобы правильно экранировать все данные. Храните сведения о конфигурации в отдельном защищенном ini-файле или даже в файле php.ini, и после этого вы можете практически игнорировать сценарии на стороне сервера.

1 голос
/ 13 февраля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...