Комментарии 18
Хорошее эссе. Точнее, зарисовки :) А за цитаты — отдельное спасибо, нечасто их в постах встретишь.
Маленькая поправка:
> если в час пик приходит неоправданно большое количество потребителей
Я бы заменил «неоправданно» на «неожиданно». Перед кем вы собираетесь оправдываться за слишком большое количество посетителей сайта? :)) Пользователей именно ожидают — и иногда их приходит неожидано много :)
Маленькая поправка:
> если в час пик приходит неоправданно большое количество потребителей
Я бы заменил «неоправданно» на «неожиданно». Перед кем вы собираетесь оправдываться за слишком большое количество посетителей сайта? :)) Пользователей именно ожидают — и иногда их приходит неожидано много :)
Интересный вывод:
> Поэтому решение с использованием объектно-ориентированных СУБД
> в качестве основы для хранения данных следует считать скорее
> очередным «велосипедом», нежели промышленным стандартом.
К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.
Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.
Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
> Поэтому решение с использованием объектно-ориентированных СУБД
> в качестве основы для хранения данных следует считать скорее
> очередным «велосипедом», нежели промышленным стандартом.
К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.
Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.
Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
Отдельное спасибо за цитаты (шутку понял и оценил:))
А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — fprog.ru/2009/issue1/eugene-kirpichev-fighting-mutable-state/
А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — fprog.ru/2009/issue1/eugene-kirpichev-fighting-mutable-state/
>> собственные решения для промежуточного слоя
Имееся в виду middleware?
По поводу разделения логики на две части — для небольших и не склонных к расширению проектов имеет смысл воспользоваться возможностью написания и развертывания в СУБД бизнес-логики не на SQL-скриптах, а на прикладном языке, который позволяет эта СУБД (для MsSQL это языки CLR, для PostgreSQL — perl, для Oracle — Java). Тогда не понадобятся простыни SQL, задачу можно решать наиболее эффективно, а БД выполняет роль и сервера приложений.
Я за продолжение «сказок»-заметок :)
Имееся в виду middleware?
По поводу разделения логики на две части — для небольших и не склонных к расширению проектов имеет смысл воспользоваться возможностью написания и развертывания в СУБД бизнес-логики не на SQL-скриптах, а на прикладном языке, который позволяет эта СУБД (для MsSQL это языки CLR, для PostgreSQL — perl, для Oracle — Java). Тогда не понадобятся простыни SQL, задачу можно решать наиболее эффективно, а БД выполняет роль и сервера приложений.
Я за продолжение «сказок»-заметок :)
Конечно middleware
Такой вариант часто рассматривается и реализуется и имеет право на жизнь,
но мне он видится как вариант, выбранный от бедности: или разработчики экономят или заказчики.
Их у меня еще есть +)
Такой вариант часто рассматривается и реализуется и имеет право на жизнь,
но мне он видится как вариант, выбранный от бедности: или разработчики экономят или заказчики.
Их у меня еще есть +)
>> как вариант, выбранный от бедности
Да не. Например, сертификация по классу безопасности предусматривает Kerberos + изоляцию за слоем хранимок/вью. С точки зрения поддержки в таком случае лучше не связываться с SQL вообще )
Или бизнес-логики не так много, чтобы выносить ее на отдельный сервер приложений. Или существующая система — двухзвенка, а доступ к данным решено переделать на более интеллектуальный.
Будем ждать =)
Да не. Например, сертификация по классу безопасности предусматривает Kerberos + изоляцию за слоем хранимок/вью. С точки зрения поддержки в таком случае лучше не связываться с SQL вообще )
Или бизнес-логики не так много, чтобы выносить ее на отдельный сервер приложений. Или существующая система — двухзвенка, а доступ к данным решено переделать на более интеллектуальный.
Будем ждать =)
P.S. Вы на java пишете, так?
Давненько упоминаний про Intersystems Cache не видел. На хабре — похоже первое. Замечательная СУБД. Замечательная статья.
ну почему же первое — я упоминал multik.habrahabr.ru/blog/59380/ и то не уверен что моё было первым
Раз уж вспомнили про каше — необходимо было вспомнить и про прямой доступ к данным — то есть к глобалам (деревьям) потому как каше поддерживает три механизма доступа к данным объектный реляционный и прямой. Прямой доступ может показаться на первом этапе более сложным — но зато он более мощный, можете посмотреть пример am.ua проекта с использованием прямого доступа к каше.
Касательно водопада подключения согласен — необходимо использовать промежуточный слой, который будет поддерживать постоянные соединения с базой и следить за очередью обращений к этим соединениям (потому как любая коммерческая СУБД имеет достаточно жёсткие ограничения на подключения и от количества одновременно доступных подключений — зависит стоимость лицензии на использование)
Касательно проблемы размещения бизнес-логики — автор попал в самую суть — здесь действительно чувствуешь себя как на минном поле, и за каждый свой шаг — потом, по мере развития проекта, придётся отвечать (как минимум перед самим собой).
В целом очень грамотная статья — видимо автор сталкивался с полным перечнем проблем описанных в статье «лицом к лицу».
Касательно водопада подключения согласен — необходимо использовать промежуточный слой, который будет поддерживать постоянные соединения с базой и следить за очередью обращений к этим соединениям (потому как любая коммерческая СУБД имеет достаточно жёсткие ограничения на подключения и от количества одновременно доступных подключений — зависит стоимость лицензии на использование)
Касательно проблемы размещения бизнес-логики — автор попал в самую суть — здесь действительно чувствуешь себя как на минном поле, и за каждый свой шаг — потом, по мере развития проекта, придётся отвечать (как минимум перед самим собой).
В целом очень грамотная статья — видимо автор сталкивался с полным перечнем проблем описанных в статье «лицом к лицу».
спасибо +) за позитивный отклик
я бы с большим удовольствием глянул на реализацию прямого доступа +)
но ктож меня пустит посмотреть,
как там винтики крутятся.
я бы с большим удовольствием глянул на реализацию прямого доступа +)
но ктож меня пустит посмотреть,
как там винтики крутятся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сказки о СУБД