Архитектуры ООСУБД. Анализ реализаций


Ответ на комментарии раздела «Следствия модели параллельности» - часть 2


В среде Versant разработчики используют запросы только для инициирования сценария использования, импортируя на сторону клиента ключевые объекты, связанные с другими объектами, которые требуются в транзакции. Затем производится навигация по связанной информации в режимах отложенной загрузки или упреждающего чтения без использования обработки запросов. Замечу также, что инициирующий запрос не является «обязательным», и что для непосредственной навигации могут использоваться именованные корневые объекты, но опыт показывает, что приложения реального мира не могут быть чрезмерно упрощенными, и для них требуются оба эти метода.

Казалось бы, Мариотт, будучи экспертом в области ООБД, должен был бы знать об этих навигационных возможностях Versant, и поэтому мне непонятно, что побудило его к обсуждению этой темы. Я согласен с тем утверждением Мариотта, что «преимущества каждой из архитектур будут сильно зависеть от контекста». Снова замечу, что в этом состоял весь смысл исходной статьи: требуется понять характеристики своего приложения и подобрать правильную архитектуру ООСУБД, соответствующую требованиям приложения. Я просто хочу, чтобы приверженцы технологии ООБД преуспели в ее применении, я вовсе не стремлюсь ввести их в то заблуждение, что некоторая ООСУБД ВСЕГДА является наилучшей. Я не буду вдаваться в детали возможностей реализации ООСУБД Versant, таких как распределенные и параллельные запросы, поскольку эти вопросы хорошо освящены в руководствах по этой системе.




Начало  Назад  Вперед



Книжный магазин