Как стать автором
Обновить

Комментарии 18

Хорошее эссе. Точнее, зарисовки :) А за цитаты — отдельное спасибо, нечасто их в постах встретишь.

Маленькая поправка:
> если в час пик приходит неоправданно большое количество потребителей

Я бы заменил «неоправданно» на «неожиданно». Перед кем вы собираетесь оправдываться за слишком большое количество посетителей сайта? :)) Пользователей именно ожидают — и иногда их приходит неожидано много :)
Да такие зарисовочки +)
Просто копятся, а на статью по отдельности не тянут +)
Решил чтобы не пропадали, оформить…

За цитаты на самом деле спасибо тем,
кто участвовал в дискуссии по вопросам СУБД и их места в ИС

Интересный вывод:

> Поэтому решение с использованием объектно-ориентированных СУБД
> в качестве основы для хранения данных следует считать скорее
> очередным «велосипедом», нежели промышленным стандартом.

К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.

Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.

Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
Мое мнение, что это не промышленный стандарт!
Отдельные удачные реализации были есть и будут.
Их будут использовать и продвигать.

Я верю,
что рано или поздно объектно-ориентированные СУБД станут основой для многих ИС,
а может и для большинства.
Отдельное спасибо за цитаты (шутку понял и оценил:))

А если по существу, то рекомендую всем интересующимся темой хранения данных почитать статью: Изменяемое состояние: опасности и борьба с ними — fprog.ru/2009/issue1/eugene-kirpichev-fighting-mutable-state/
>> собственные решения для промежуточного слоя
Имееся в виду middleware?

По поводу разделения логики на две части — для небольших и не склонных к расширению проектов имеет смысл воспользоваться возможностью написания и развертывания в СУБД бизнес-логики не на SQL-скриптах, а на прикладном языке, который позволяет эта СУБД (для MsSQL это языки CLR, для PostgreSQL — perl, для Oracle — Java). Тогда не понадобятся простыни SQL, задачу можно решать наиболее эффективно, а БД выполняет роль и сервера приложений.

Я за продолжение «сказок»-заметок :)
Конечно middleware

Такой вариант часто рассматривается и реализуется и имеет право на жизнь,
но мне он видится как вариант, выбранный от бедности: или разработчики экономят или заказчики.

Их у меня еще есть +)
>> как вариант, выбранный от бедности
Да не. Например, сертификация по классу безопасности предусматривает Kerberos + изоляцию за слоем хранимок/вью. С точки зрения поддержки в таком случае лучше не связываться с SQL вообще )
Или бизнес-логики не так много, чтобы выносить ее на отдельный сервер приложений. Или существующая система — двухзвенка, а доступ к данным решено переделать на более интеллектуальный.

Будем ждать =)
P.S. Вы на java пишете, так?
Предпочитаю +)
Так и подумал, особенно после того, как упомянули про Connection Pool (ну и middleware слегка). «Клятый» майкрософт для .net реализовал все коннекшены с автопулингом (настраивается через ConnectionString), так что у .net программистов такая мысль просто не возникает :)
Дело в том, что чистыми пулами уже давно не пользуются.
Все обычно спрятано в датасорсы и JDBC драйвера,
которые используют паттерн прокси,
для слежения за закрытием и обеспечением не закрытия злосчастных подключений.

Ну и конечно клятые ORM-фреймворки +)
Давненько упоминаний про Intersystems Cache не видел. На хабре — похоже первое. Замечательная СУБД. Замечательная статья.
ну почему же первое — я упоминал multik.habrahabr.ru/blog/59380/ и то не уверен что моё было первым
Раз уж вспомнили про каше — необходимо было вспомнить и про прямой доступ к данным — то есть к глобалам (деревьям) потому как каше поддерживает три механизма доступа к данным объектный реляционный и прямой. Прямой доступ может показаться на первом этапе более сложным — но зато он более мощный, можете посмотреть пример am.ua проекта с использованием прямого доступа к каше.

Касательно водопада подключения согласен — необходимо использовать промежуточный слой, который будет поддерживать постоянные соединения с базой и следить за очередью обращений к этим соединениям (потому как любая коммерческая СУБД имеет достаточно жёсткие ограничения на подключения и от количества одновременно доступных подключений — зависит стоимость лицензии на использование)

Касательно проблемы размещения бизнес-логики — автор попал в самую суть — здесь действительно чувствуешь себя как на минном поле, и за каждый свой шаг — потом, по мере развития проекта, придётся отвечать (как минимум перед самим собой).

В целом очень грамотная статья — видимо автор сталкивался с полным перечнем проблем описанных в статье «лицом к лицу».
спасибо +) за позитивный отклик

я бы с большим удовольствием глянул на реализацию прямого доступа +)
но ктож меня пустит посмотреть,
как там винтики крутятся.
ну прям вживую посмотреть — конечно никто не даст — но описать как это у нас сделано — я могу — правда говоря по правде — реализация пока что очень далека от совершенства — но если это интересно — могу продолжить писать про Каше — а что в первую очередь Вас интересует напишите в коментариях
так вы опишите +)
в чем разница между всеми тремя видами
будет отличная статья
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории