Почему OODBMS не так широко распространены как RDBMS?
Чтобы подробно остановиться на других ответов дали:
у Нас есть много языков с большим количеством символов, которые должны идеально отобразить компьютеры. Unicode присваивает каждому символу уникальный номер или кодовую точку.
Компьютерное соглашение с такими числами как байты... пропускающие немного истории здесь и игнорирующие проблемы решающего памяти, 8-разрядные компьютеры, рассматривало бы 8-разрядный байт как самую большую числовую единицу, легко представленную на аппаратных средствах, 16-разрядные компьютеры развернут это до двух байтов и т.д.
Старые кодировки символов, такие как ASCII от (пред-) 8-разрядная эра и пытаются переполнить доминантный язык в вычислениях в то время, т.е. английский язык, в числа в пределах от от 0 до 127 (7 битов). С 26 буквами в алфавите, и в капитале и в непрописной форме, числах и знаках пунктуации, которые работали вполне прилично. ASCII был расширен 8-м битом для другого, неанглийские языки, но дополнительные 128 чисел/кодовых точек сделали доступным этим расширением, будут отображены на различных символах в зависимости от отображаемого языка. Стандарты ISO 8859 являются наиболее распространенными формами этого отображения; ISO-8859-1 и ISO-8859-15 (также известный, поскольку ISO-Latin-1, latin1, и да там являются двумя различными версиями 8 859 стандартов ISO также).
, Но это недостаточно, когда Вы хотите представить символы больше чем с одного языка, таким образом, зубрежка все доступные символы в единственный байт просто не будет работать.
существует по существу два различных типов кодировки: каждый разворачивает диапазон значений путем добавления большего количества битов. Примерами этой кодировки был бы UCS2 (2 байта = 16 битов) и UCS4 (4 байта = 32 бита). Они страдают от по сути той же проблемы как ASCII и стандарты ISO 8859, как их диапазон значений все еще ограничен, даже если предел значительно выше.
другой тип кодирования использования переменное число байтов на символ и обычно известная кодировка для этого являются кодировкой UTF. Вся кодировка UTF работает примерно тем же способом: Вы выбираете размер единицы, который для UTF-8 составляет 8 битов, поскольку UTF-16 составляет 16 битов, и для UTF-32 32 бита. Стандарт тогда определяет несколько из этих битов как флаги: если они установлены, то следующую единицу в последовательности единиц нужно считать частью того же символа. Если они не установлены, эта единица представляет один символ полностью. Таким образом наиболее распространенные символы (English) только занимают один байт в UTF-8 (два в UTF-16, 4 в UTF-32), но другие символы языка могут занять шесть байтов или больше.
Многобайтовая кодировка (я должен сказать, что мультиединица после вышеупомянутого объяснения) имеют преимущество, что они относительно эффективны пространством, но оборотная сторона, что операции, такие как нахождение подстрок, сравнений, и т.д. все должны декодировать символы к unicode кодовым точкам перед такими операциями, может быть выполнена (существуют некоторые ярлыки, хотя).
И стандарты UCS и стандарты UTF кодируют кодовые точки, как определено в Unicode. В теории та кодировка могла использоваться для кодирования любого числа (в диапазоне поддержки кодирования) - но конечно эта кодировка была сделана закодировать кодовые точки Unicode. И это - Ваши отношения между ними.
Windows обрабатывает так называемые строки "Unicode" как строки UTF-16, в то время как большая часть значения по умолчанию UNIXes к UTF-8 в эти дни. Коммуникационные протоколы, такие как HTTP имеют тенденцию работать лучше всего с UTF-8, поскольку размер единицы в UTF-8 совпадает с в ASCII, и большинство таких протоколов было разработано в эру ASCII. С другой стороны, UTF-16 дает лучшее среднее число производительность пространства/обработки при представлении всех живых языков.
стандарт Unicode определяет меньше кодовых точек, чем можно представить в 32 битах. Таким образом для всех практических целей, UTF-32 и UCS4 стали тем же кодированием, как Вам придется вряд ли иметь дело с символами мультиединицы в UTF-32.
Hope, которая заполняет некоторые детали.
6 ответов
Одна из причин того, что СУБД сохранила популярность, заключается в том, что это устоявшаяся технология, хорошо понятная и имеющая стандартный язык (SQL), поддерживаемый несколькими поставщиками. Он также имеет несколько хороших интерфейсов, таких как ODBC и JDBC, которые позволяют ему довольно хорошо взаимодействовать с разными языками. Стабильный API - сильный фактор в сохранении доминирующей роли технологии.
Напротив, нет четкой модели для OODBMS, нет стандартного языка и стандартного API. Нет даже стандарта де-факто при наличии реализации ведущего поставщика
. Концепция OODBMS могла бы работать лучше, чем RDBMS + ORM. Это полностью зависит от реализации. Но верно также и то, что ООСУБД не решает тот же набор проблем, что и РСУБД. Некоторые задачи управления данными намного проще, если у вас есть ссылочная целостность и реляционные заголовки, обеспечиваемые решением для управления данными. Эти функции отсутствуют в модели ООСУБД (по крайней мере, пока).
В блогах много шума о том, что реляционные базы данных устарели, но РСУБД, тем не менее, являются лучшим универсальным решением для подавляющего большинства задач управления данными.
Данные часто живут дольше и важнее программы. Так что даже если вы начнете разработку с нуля сегодня, вы должны рассмотреть общую картину. С системами RDBM работает больше инструментов, процессов и опытных людей. Не ограничиваясь программой, подумайте о планировании мощностей, интеллектуальном анализе данных, отчетности, ETL, интеграции с другими источниками данных и т. Д. Как насчет того, чтобы ваша компания приобрела другую компанию и, таким образом, включила все ее реляционные данные в вашу программу. РСУБД и связанные с ними инструменты настолько укоренились, Может быть, в какой-нибудь маленькой нише, но не в целом.
Я думаю, что это случай
Если он не сломался, не меняйте его.
Реляционные базы данных чрезвычайно укоренились.
Одним словом Функциональная совместимость (громкое слово в пятницу вечером
Большинству предприятий приходится работать с устаревшими системами, работающими на РСУБД. Если бы они использовали OODBMS, им все равно потребовался бы доступ к RDBMS для определенных функций. Легче поддерживать один способ доступа к данным, чем два.
Если у вас есть такие громкие имена, как Oracle и SQL Server, в мире OODBMS и доказанная производительность в различных средах, ТОГДА вы увидите больше проектов, использующих их.
Объектные базы данных занимают очень удобную нишу для таких задач, как представление геометрии, например, в системах САПР, где графы объектов могут быть действительно очень глубокими. Производительность JOIN быстро снижается примерно для 7 таблиц в большинстве реляционных систем, поэтому глубоко самореферентные структуры в САПР лучше работают в объектных базах данных.
Но важные приложения, такие как финансовые данные, поддаются реляционному представлению. Реляционная модель имеет прочную математическую основу, а SQL - успешный и популярный язык. У финансовых институтов, таких как банки, брокерские и страховые компании, мало стимулов к отказу от СУБД.
Самая большая проблема, которую я видел, - это отсутствие стандартизации. В мире СУБД вы можете довольно далеко продвинуться с любой случайной базой данных, если знаете SQL. Практически все они реализуют его с небольшими вариациями. Я не знаю ни одной существующей СУБД, которая не поддерживает SQL: вы можете почти взаимозаменяемо использовать "СУБД" и "SQL".
Самым близким к OODBMS, возможно, является OQL, который оказался полным провалом.
Ни одна база данных никогда не реализовывала его в значительной степени. Пару лет назад я использовал довольно хорошие коммерческие ООСУБД, но (примерно в 2007 году и это было в основной версии 8 или 9) он даже не поддерживал запросы объекта по его имени. В руководстве просто сказано, что к этой части OQL они еще не дошли. (Я не уверен, но вы могли бы перейти к нативному вызову для этого.)
Большинство объектных баз данных, которые я недавно видел, имеют интерфейсы на родном языке, а не язык запросов, такой как OQL. Система, которую я использовал, например, поддерживала (только!) Perl и VB, IIRC. Ограничение вашей аудитории парой языков (или принуждение их к написанию оболочек, как мы) - не способ завоевать друзей.
Из-за этого нет конкуренции, и, следовательно, нет простого плана резервного копирования. Если вы поместили свои данные в MS-SQL, а Microsoft перестала его поддерживать, вы, вероятно, сможете сбросить данные в Postgres и перенести свои запросы без особых проблем. (Это может потребовать много работы, если у вас много запросов, но я не сомневаюсь, что вы сможете это сделать. Это больно, но технически не сложно.) Или Oracle, или MySQL, или многие другие, оба коммерческие и бесплатно.
Такой вещи не существует с OODBMS: если тот, который вы используете, выходит из строя, или они направляют его в направлении, которое вам не подходит, или вы обнаружите, что в нем отсутствует важная вам функция, вы не можете просто выгружать данные в конкурирующую OODBMS и переносить запросы. Вместо этого вы говорите об изменении базовой библиотеки и внесении серьезных изменений в архитектуру. На самом деле, вы ограничены коммерческой OODBMS, которой вы действительно доверяете (вы можете назвать хотя бы одну?), Или OODBMS с открытым исходным кодом, которую ваша команда будет поддерживать, когда дела пойдут плохо.
Если это звучит как FUD Извините, я этого не планировал. Но я был там, и с точки зрения управления проектами я бы не стал возвращаться, хотя среда программирования может быть замечательной. Другой способ думать об этом: посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. ООСУБД похожи на это, но хуже, потому что это не только ваш код, но и ваш код, и ваши данные. Я бы с радостью начал крупный проект в Erlang сегодня, но я все равно не решусь использовать OODBMS.
Поставщики OODBMS: чтобы изменить это, вам нужно упростить переход к вашим конкурентам . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Я не решаюсь вернуться, даже если среда программирования может быть замечательной. Можно подумать по-другому: посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. ООСУБД похожи на это, но еще хуже, поскольку это не только ваш код, но и ваш код, и ваши данные. Я бы с радостью начал сегодня крупный проект в Erlang, но я все равно не решусь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить процесс ухода за конкурентами . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Я не решаюсь вернуться, хотя среда программирования может быть замечательной. Можно подумать по-другому: посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. ООСУБД похожи на это, но еще хуже, поскольку это не только ваш код, но и ваш код, и ваши данные. Я бы с радостью начал сегодня крупный проект в Erlang, но я все равно не решусь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить процесс ухода за конкурентами . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. ООСУБД похожи на это, но еще хуже, поскольку это не только ваш код, но и ваш код, и ваши данные. Я бы с радостью начал сегодня крупный проект в Erlang, но я все равно не решусь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить процесс ухода за конкурентами . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. ООСУБД похожи на это, но еще хуже, поскольку это не только ваш код, но и ваш код, и ваши данные. Я бы с радостью начал крупный проект в Erlang сегодня, но я все равно не решусь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить переход к вашим конкурентам . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Я все еще не решаюсь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить переход от вас к конкурентам . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.
Я все еще не решаюсь использовать OODBMS.Поставщики OODBMS: чтобы изменить это, вам нужно упростить переход от вас к конкурентам . Вы можете откопать OQL и реализовать его, или сделать это на уровне API, например ODBC, или что-то еще. Даже стандартный формат дампа (с использованием JSON?) И инструменты для импорта / экспорта в / из него для нескольких OODBMS были бы отличным началом.