В рамках проекта postgres-js (http://github.com/commandprompt/postgres-js) подготовлен (http://permalink.gmane.org/gmane.comp.db.postgresql.announce...) драйвер, представляющий собой реализацию на языке JavaScript протокола для сетевого взаимодействия с СУБД PostgreSQL. Драйвер может быть использован в серверных JavaScript-проектах, выполняемых под управлением платформы node.js (http://nodejs.org/), позволяющей создавать высокопроизводительные сетевые программы на языке JavaScript.Драйвер включает в себя поддержку параметризованных запросов (экранирование спецсимволов выполняется на стороне PostgreSQL), ограниченных Javascript-блоками транзакций (in-Javascript
transactions), агрегирования группы запросов в единый логический блок (передаваемые по отдельности запросы накапливаются и выполняются единовременно).URL: http://permalink.gmane.org/gmane.comp.db.postgresql.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=28252
ИМХО извращение какое-то... Обращение к СУБД из Javascript'а...
По вашему надо данные из пальца высасывать, как вконтакт о своей статистике (которая продолжает "генериться" при полном отсутствии инета)?
нет конечно, просто в нормальной ситуации приложение (если говорить о веб приложениях по крайней мере) делиться на 3 уровня. По сути это уровень данных (чаще всего СУБД, но не всегда), уровень бизнеслогики и уровень отображения.
Так вот, в правильном с точки зрения архитектуры проиложении уровень отображения контактирует только с уровнем бизнеслогики, но никак не с уровнем данных.А то что предлагается - это залог кривой архитектуры.
Хотя, конечно, я могу заблуждаться. Может это предназначено не для Web или предлагается и уровень бизнес логики писать на JavaScript. Но честно говоря опираясь на опыт работы с JS, это не тот язык на котором следовало бы писать бизнес логику. ИМХО
>Драйвер может быть использован в серверных JavaScript-проектах, выполняемых под управлением платформы node.jsРечь идет не о клиентском JS.
Наш опыт заставляет нас думать по готовым шаблонам; сейчас действительно наметитась тенденция переносить бизнес логику на сторону клиента. Если протокол обеспечивает безобасность, почему бы и нет?
>>высокопроизводительные сетевые программы на языке JavaScriptЕсть сомнения
http://sysoev.ru/prog/v8.html
>>Время создания контекста — 2 миллисекунды. Конечно, когда контекст создаётся для каждой >>страницы в браузере, пользователь эти 2 миллисекунды не заметит, но если сервер будет >>создавать контекст для каждого запроса, то это означает, что он может создать в секунду не >>более 500 контекстов и, следовательно, не сможет обработать больше 500 запросов в секунду.
Про кэширование запросов слыхали?
у меня long-poll сервер на nodejs обрабатывает в секунду 1500 запросов, что я не так делаю?
дело в том, что новый контекст нужен для запросов аля пхп, а для демонов он создается один раз
> http://sysoev.ru/prog/v8.htmlА что, кроме V8, других серверных JS-движков нет?
В рамках проекта подготовки к преобразованию PostgreSQL в OracleDB подготовлен драйвер, представляющий собой реализацию на языке JavaScript протокола для сетевого взаимодействия с СУБД PostgreSQL
Брр. Javascript вообще уродливый язык (на зря он на StackOverflow занялд первое место по колиечству идиотизмов в языке), и применять его там, где можно без него обойтись... брр. Тем более, что динамически типизированные языки склонны не замечать тупые ошибки "по определению".
есть ещё haxe, который помимо прочего транслируется и в php , и в js - такая вот интересная задумка писать и тестировать прототип на одном языке, а production код генировать для той платформы где ему работать. Не всё конечно так розово как кажется, но идея интересная. http://www.haxe.org
Он лучше крестов и минималистичнее пыха и для него есть очень быстрые интерпретаторы.