Плюсы и минусы многозначных баз данных

Question

Я только что начал новую работу, где мне придется проделать большую работу с многозначной базой данных (UniVerse).У меня мало опыта работы с базами данных в реляционных базах данных (SqlServer), и я ищу некоторую непредвзятую информацию о том, какие плюсы и минусы МВД сравниваются с реляционными базами данных.

Все в офисе тожеприбывает из реляционной базы данных (и ненавидит UniVerse) или был здесь в течение многих лет и любит это.

Answer 1

Во-первых, отказ от ответственности. Я работаю с UniData (дочерняя БД UniVerse) и иногда блог на нем , поэтому я не могу претендовать на то, чтобы быть абсолютно беспристрастным; Я постараюсь, однако.

Вот несколько соображений для вас:

• Большая разница между базой данных SQL и многозначной базой данных заключается в том, что MVDB не соответствует 1NF . Это имеет свои плюсы и минусы. Им можно (и обычно) злоупотреблять, но бывают случаи, когда он может быть чрезвычайно функциональным. Самым большим преимуществом является то, что вам не всегда нужна таблица соединений, которая может выполнять определенные запросы намного быстрее.

• Хранит метаданные совершенно новым способом по сравнению с обычными базами данных SQL. Каждый файл / таблица не имеет конкретной схемы. Вместо этого он имеет 1 или более «словарных» файлов, которые состоят из записей, которые сообщают вам, как следует интерпретировать данные. Это позволяет вам не только хранить несколько интерпретаций данных (необработанные / прописные / строчные буквы, комбинированные поля и т. Д.), Но также позволяет выполнять эквивалент перечислений и объединений. Это может быть чрезвычайно мощным, если все сделано правильно .

• К сожалению, хотя концепция имеет большой потенциал, набор инструментов СУБД отсутствует. Разработка ведется, но чрезвычайно малый набор бизнес-кейсов, по-видимому, обусловлен менталитетом «оставайся в курсе» существующих и устаревших программных систем, которые были построены на нем. Хотя у него есть инструменты для интеграции (такие как коннекторы .NET, интерфейс ODBC для запросов SQL и т. Д.), У них есть проблемы. Например, в интерфейсе UniObjects .NET отсутствует какая-либо грануляция в области безопасности (в основном все или ничего).

• Это не просто СУБД, а по сути целая платформа приложений. Несмотря на то, что UniBasic не так мощен, как, скажем, язык на основе .NET, он наверняка обойдёт T-SQL и быстро развернет процесс выработки бизнес-правил.

Answer 2

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

Это действительно зависит от того, что вы пытаетесь сделать, как данные должны быть структурированы, и какие другие инструменты у вас есть.Я провожу большую часть своего времени, работая в MV (в основном продукты Revelation), и мы регулярно обрабатываем наборы записей в 10 000 000+, и скорость хорошая.

Сила базы данных MV - это когда данные текучие.Мы находим, что большинство наших клиентов используют его для таких приложений, как юридические, медицинские и финансовые продукты;приложения, в которых отношения сложны и могут быстро и радикально меняться со временем.

Возможно, вы захотите просмотреть движение без SQL, которое разделяет многие из тех же концепций, даже если MV и SQL на самом деле не являются таковыми.то же самое.

Основной недостаток MV меньше в его структуре, чем в его инструментах.Как правило, вы обнаружите, что, поскольку база разработчиков меньше, доступный инструментарий и справка меньше.Вы также можете обнаружить, что во встроенном базовом языке, который дает вам большинство предложений, отсутствует кодировка стилей объекта, к которой вы привыкли.Временами даже кажется, что JavaScript обладает большей функциональностью как язык.

Сказав, что, поскольку базы данных MV в основном представляют собой гигантские строки, обработка языков в языках превосходна.Они отлично подходят для прямой манипуляции со строками HTML и XML.

Полагаю, у меня большой вопрос, у вас есть конкретные вопросы?Я не собираюсь начинать войну, говоря, что это похоже на переход с Windows на Linux или Mac или даже на переход с Debian на Red Hat, но структуры и системы разные, поэтому у них разные концепции, сильные стороны, ограничения и цели.,Если вы попытаетесь обработать базу данных MV, такую ​​как SQL (что вы можете), вы обнаружите, что она не подходит лучше всего.Плохо спроектированная база данных MV может быть упражнением в фрустации.Хорошо спроектированная база данных MV может быть прекрасной вещью.

Answer 3

Базы данных

MV известны тем, что вытесняют потрясающую производительность из серверов с относительно низкой мощностью.

Они используют систему хранения ссылок на хэш, которая сводит большинство операций доступа к файлу к математической операции и считыванию одного диска, когда известен ключ записи.В правильно сконфигурированной системе чтение из файла с 1 000 000 000 записей занимает не больше времени, чем из файла с 1 000 записей, пока известен ключ записи.

Ключи записи должны быть уникальными, и в приложениях, где ключ записи может быть настроен таким образом, чтобы его можно было определить алгоритмически или программно, накладные расходы, связанные с доступом к базе данных, могут быть минимальными.Но, конечно, это обычно включает доступ к базе данных способами, которые, вероятно, не будут считаться «реляционными».

Answer 4

Нет плюсов и минусов как таковых - они просто используют разные методы для хранения значений. UniVerse использует разделитель для разделения значений (IIRC использует char (254) и char (253) для разделения нескольких значений в поле и char (255) для разделения фактических записей в файле данных. Я могу ошибаться хотя - прошло более 10 лет с тех пор, как я последний раз его использовал). Некоторые люди любят этот метод хранения данных, точно так же как некоторые люди все еще предпочитают винтажные автомобили более поздним моделям, или некоторые люди предпочитают использовать лошадь и телегу вместо современного автомобиля. (Конечно, это только мое мнение).

Хранение нескольких значений в поле означает, что у вас нет дополнительной таблицы, которую использовал бы SQLServer, у вас фактически есть уровень денормализации. Использовать эти множественные значения очень просто и хорошо, если использовать технологию, изначально встроенную в UniVerse (мы использовали систему управления окнами под названием CueBIC), но она становится PITA при подключении к базе данных с другого языка, такого как C ++ или VB - тогда Вы должны прочитать запись и выделить значения самостоятельно. Это означает, что было также трудно найти эти мульти значения.

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

Answer 5

Масштабирование до большого количества элементов (записей) в файлах работает хорошо. Масштабирование до большого количества значений или вложенных значений в записях создаст проблемы с производительностью. Дизайн приложения должен быть чувствительным к ограничению списков значений и поднаборов ниже порога в несколько тысяч.

Отличная обработка строк. Как и целочисленная обработка. Языки MV Basic слабо типизированы, поэтому не ждите от компилятора слишком многого. Тем не менее, поскольку исходные элементы MV Basic похожи на любые другие данные, а компилятор - это просто еще один глагол в среде БД, написание генераторов и прекомпиляторов кода - это очень просто. Это хорошая среда для создания слоя инструментов под вашим приложением.