Я только что начал новую работу, где мне предстоит сделать много работы с многозначной базой данных (UniVerse). Какой небольшой опыт работы с базой данных я имею в реляционных базах данных (SqlServer), и я ищу какую-то непредвзятую информацию о том, какие плюсы и минусы MVD сравниваются с реляционными базами данных.
Все в офисе либо исходят из реляционной базы данных (и ненавидят UniVerse), либо здесь уже много лет и любят ее.
Во-первых, отказ от ответственности. Я работаю с UniData (сестра DB UniVerse), а иногда блог на нем, поэтому я не могу утверждать, что я полностью непредвзято; Однако я постараюсь.
Вот несколько соображений для вас:
Большая разница между SQL DB и многозначным DB заключается в том, что MVDB не придерживается 1NF. У этого есть плюсы и минусы. Это может быть (и обычно) злоупотребление, но есть моменты, когда он может быть чрезвычайно функциональным. Самое большое преимущество в том, что это означает, что вам не всегда нужна таблица соединений, которая может ускорить выполнение определенных запросов.
Он сохраняет метаданные совершенно новым способом по сравнению с обычными SQL-базами данных. Каждый файл/таблица не имеет конкретной схемы. Вместо этого у него есть 1 или более "словарных" файлов, которые состоят из записей, которые рассказывают вам, как данные должны интерпретироваться. Это позволяет не только хранить несколько интерпретаций данных (raw/uppercase/lowercase, комбинированные поля и т.д.), Но также позволяет выполнять эквивалент перечислений и объединений. Это может быть чрезвычайно мощным, если все сделано правильно.
К сожалению, хотя концепция имеет большой потенциал, набор инструментов СУБД отсутствует. Развитие обусловлено, но чрезвычайно небольшим набором дел, которые, как представляется, обусловлены менталитетом существующих и стареющих программных систем, которые были построены на нем. Хотя у него есть инструменты для интеграции (такие как .NET-коннекторы, интерфейс ODBC для SQL-запросов и т.д.), У них есть проблемы. Например, интерфейс UniObjects.NET не имеет грануляции в безопасности (в основном все или ничего).
Это не просто СУБД, а, по сути, целая платформа приложений. Несмотря на то, что UniBasic не так силен, как говорят на языке, основанный на .NET, он уверен, что удаляет штаны с T-SQL и быстро поворачивается для выкидывания бизнес-правил.
Как предложил Дейв, базы данных MV действительно разработаны, чтобы работать лучше всего, когда вы знаете ключ к записи, которую вы пытаетесь извлечь. Некоторые люди называют их базами данных на основе записей, в отличие от SQL, которая представляет собой систему баз данных на основе набора.
Это действительно зависит от того, что вы пытаетесь сделать, как нужно структурировать данные и какие другие инструменты у вас есть. Я провожу большую часть своего времени, работая в MV (продукты Откровения, в основном), и мы регулярно обрабатываем наборы записей в 10 000 000+, и скорость в порядке.
Сила базы данных MV - это когда данные являются текучими. Мы находим, что большинство наших клиентов используют его для таких приложений, как юридические, медицинские и финансовые продукты; приложения, где отношения сложны и могут быстро и резко меняться с течением времени.
Возможно, вам захочется взглянуть на движение без SQL, которое разделяет многие из тех же понятий, хотя MV и SQL не являются тем же самым.
Основной недостаток MV меньше в структуре, чем в инструментах. Обычно вы обнаружите, что, поскольку база разработчиков меньше, набор инструментов и доступная помощь меньше. Вы также можете обнаружить, что встроенный базовый язык, в котором большинство предложений дает вам недостаток в стиле стиля, к которому вы привыкли. Бывают времена, даже JavaScript кажется, что он имеет больше функциональности в качестве языка.
Сказав это, поскольку базы данных MV являются в основном гигантскими строками, обработка строк в языках превосходна. Они отлично подходят для непосредственного управления строкой HTML и XML.
Я полагаю, что у меня есть большой вопрос, есть ли у вас конкретные вопросы? Я не собираюсь открывать войну, говоря, что это как переход от Windows к Linux или Mac или даже переход от Debian к Red Hat, но структуры и системы разные, поэтому у них разные концепции, сильные стороны, ограничения и цели, Если вы попытаетесь обработать базу данных MV, такую как SQL (что вы можете), вы найдете ее не лучшим образом. Плохо спроектированная база данных MV может быть упражнением в усечении. Хорошо спроектированная база данных MV может быть прекрасной.
Базы данных MV знают, что они выдают потрясающую производительность из серверов с относительно низким энергопотреблением.
Они используют систему регистрации ссылок-хешей, которая уменьшает большинство операций доступа к файлам до математической операции, и один диск считывается, когда ключ записи известен. В правильно настроенной системе чтение из файла с 1 000 000 000 записей занимает не больше, чем из файла с 1000 записями, пока известен ключ записи.
Ключи записи должны быть уникальными, а в приложениях, где ключ записи может быть настроен таким образом, что его можно определить алгоритмически или программно, служебные данные, связанные с доступом к базе данных, могут быть минимальными. Но, конечно, обычно это касается доступа к базе данных способами, которые, вероятно, не будут считаться "реляционными".
В этом нет никаких плюсов и минусов - они просто используют разные методы для хранения значений. UniVerse использует разделитель для разделения значений (IIRC использует char (254) и char (253) для разделения нескольких значений в поле и char (255) для разделения фактических записей в данных файл. Возможно, я ошибаюсь - прошло более 10 лет с тех пор, как я его последний раз использовал). Некоторым людям нравится этот метод хранения данных, так же, как некоторые люди по-прежнему предпочитают старинные автомобили по поздним модельным, или некоторые предпочитают использовать лошадь и телегу вместо современного автомобиля. (Конечно, это только мое мнение).
Сохранение нескольких значений в поле означает, что у вас нет дополнительной таблицы, которую SQLServer использовал бы, вы фактически имеете уровень денормализации. Использование этих многозначных значений легко и полезно при использовании технологии, которая изначально идет с UniVerse (мы использовали систему окон CueBIC), но она становится PITA при подключении к базе данных с другого языка, такого как С++ или VB, - тогда вы должны прочитать запись и отдельно выделить ценности. Это означает, что также было сложно выполнить поиск по этим многозначным значениям.
Но опять же, может быть, все изменилось с тех пор, как я его последний раз использовал, может быть, кто-то написал хороший драйвер, чтобы вы могли легко взаимодействовать с UniVerse с платформы .NET. Надеюсь, что они у вас есть.
Масштабирование большого количества элементов (записей) в файлах работает хорошо. Масштабирование большого количества значений или под-значений в записях создаст проблемы с производительностью. Конструкция приложения должна быть чувствительной к предельным значениям и спискам значений ниже порога 1000.
Обработка строк превосходна. Как целочисленная обработка. Основные языки MV Basic типизированы, поэтому от компилятора не ожидайте слишком много принудительного исполнения. Тем не менее, поскольку исходные элементы MV Basic подобны любым другим данным, а компилятор - это всего лишь еще один глагол в среде БД, написание генераторов кода и предварительных компиляторов - легкий ветерок. Это хорошая среда для создания слоя инструментов ниже вашего приложения.