Разработка реляционного лагеря и базы данных "реального мира" - PullRequest
6 голосов
/ 27 сентября 2008

Прошло более десяти лет с момента первой публикации Дейта и Дарвена "Третий манифест" в 1995 году.

Какое место занимает школа мышления в современном мире баз данных? Есть ли доказательства того, что идеи Манифеста изменили основные методы разработки программного обеспечения и управления данными? Катализировали ли они создание новых продуктов для управления данными? Являются ли эти продукты коммерчески успешными?

Ответы [ 7 ]

10 голосов
/ 28 сентября 2008

В течение многих лет я видел много дискуссий о том, как OOD должны превосходить реляционные базы данных «в ближайшее время»; что реляционная модель - это путь прошлого; эта инерция от огромной установленной базы (эм ... legacy ) - это то, что сдерживает прогресс в OOD. «Это всего лишь вопрос времени, когда« достаточно хорошая »реализация, наконец, выйдет и преуспеет в свертывании СУРБД».

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

В большинстве сценариев "реального мира" важная вещь, единственное, что имеет значение, это данные .

Методы программирования, инструменты и языки меняются; технология развивается. Корпоративные «Системы голосового реагирования» становятся яростью, а затем исчезают в тени «Сети». Приложения приходят и уходят; некоторые из них хорошие, некоторые не очень; некоторые критические, некоторые просто удобные; некоторые последние 3 месяца, некоторые последние 3 десятилетия. Но, в конце концов, информация, которая питает все эти приложения, является «1011 * сердцем * 1012» системы и должна пережить колебания моды. Данные остаются .

Итак, ядро ​​«Системы» должно развиваться вокруг одной цели: хранить и защищать данные.

Подумайте об этом: в частности, базы данных SQL дают нам автономный, (в основном) стандартизированный репозиторий с проверенной десятилетиями записью, и к нему можно получить доступ в любое время, что далеко не устарело, по сути является Функциональным язык! Это очень хорошее место, где можно доверять вашему наиболее ценному компоненту.

Любой подход, который отдает приоритет инструменту программирования, среде или приложению за счет сохранения данных в скрытом хранилище - все, что связывает технологию приложения слишком близко к данным, может потерпеть неудачу Обочина.

Не сказать, что я верю, что все в мире должно входить в таблицу SQL. У OOD-подобных решений тоже есть место и большой потенциал. Но вам нужно искать места, где «приложение» является королем, а «данные» второстепенными: игры, одноразовые приложения и инструменты, системы, которые содержат некритические данные или данные, которые не имеют долгосрочной ценности в прошлом. ожидаемая продолжительность жизни приложения.

В частности, я думаю, что системы, которые имеют ограниченный срок полезного использования (не более нескольких лет), являются основными кандидатами на OOD-подобные технологии. С другой стороны, работая над чем-либо, что однажды должно «передать» данные его преемнику, я бы очень остерегался всего, кроме старых добрых СУБД.

Чтобы поместить это в звуковой байт, это никогда не было о "приложении"; Это всегда было о "данных".

4 голосов
/ 27 сентября 2008

Объектно-ориентированные базы данных - оксюморон. чем больше вы пытаетесь создать базу данных ОО, тем больше вы попадаете в реляционный мир. по моему мнению, они просто обман. Обратите внимание, что ORM не являются базами данных OO. Ни наборы данных. Я уже слышал этот аргумент, поэтому говорю это просто, чтобы прояснить ситуацию.

1 голос
/ 27 сентября 2008

При обработке бизнес-данных реляционная модель прочно укоренилась и не может быть удалена. Он является центральным и часто чрезмерно используется для неуместных вещей. Люди будут использовать (злоупотреблять) реляционную базу данных в качестве надежной очереди сообщений, потому что - ну, они видят каждую проблему как проблему базы данных.

Реляционная модель является основой многих (почти всех) коммерческих продуктов для каждого бизнес-процесса. Трудно найти что-то, что не является принципиально реляционным. Действительно, во многих случаях продукты тесно связаны с базой данных. Финансовые показатели Oracle, учет Microsoft Dynamics и т. Д.

В обозримом будущем хранилища реляционных данных станут основным хранилищем для обработки бизнес-данных.

В настоящее время реляционные базы данных само собой разумеется. Все спрашивают, «какой механизм базы данных», чтобы они могли влиять на дебаты между Oracle, IBM, Microsoft и MySQL. Никто не спрашивает, "какой будет модель данных? Объектная или реляционная?"

ORM продолжит проникать. Объектно-ориентированное программирование будет продолжать расти, приводя к все большему количеству ORM. Вырваться из этой рамки сложно - почти невозможно - потому что ИТ-бизнес ориентирован на стабильность, а не на инновации. Их целью почти всегда является "Keep The Lights On". Это означает отказ от изменений до тех пор, пока поставщик не прекратит их работу или не прекратит поддержку продукта.

1 голос
/ 27 сентября 2008

Пока что появившиеся OODBMS не имеют такого широкого распространения, как хотелось бы некоторым, и причина была проста: OODBMS решают только проблемы разработчиков ООП, но не все остальные , который включает администраторов баз данных, аналитиков, специалистов по MIS и огромное количество разработчиков, которые не являются объектно-ориентированными, а вместо этого «ориентированы на данные».

При этом в СУБД остается огромное количество корпоративных данных, аналогично тому, как огромное количество корпоративных данных также остается в системах на основе COBOL / CICS.

Что касается фактов, вы можете часами искать в Google статистику, но вы ее не найдете. Все, что вы найдете, это Oracle против MS SQL Server против MySQL / PostGre / других статистик принятия СУБД с открытым исходным кодом друг против друга, а OODBMS, такие как db4o, в значительной степени игнорируются.

1 голос
/ 27 сентября 2008

Мы видим, как моделирование объектов выходит на свет для управления нашими данными. У нас есть Linq и NHibernate, которые позволяют нам отображать данные в базе данных на объекты в нашем коде. Тем не мение. Я думаю, что нам еще далеко до реальной объектно-ориентированной базы данных. Я не уверен, что мы когда-либо будем. Хотя работа с «объектами» имеет свои преимущества, обработка данных как наборов с помощью реляционной модели данных имеет много преимуществ.

0 голосов
/ 28 сентября 2008

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

0 голосов
/ 27 сентября 2008

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

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

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

Работает для запросов, возвращающих 1 результат на миллион - и модель класса очень легко реплицировать - поскольку в основном все внутренние переменные данных класса являются просто полями в наборе записей.

...