Системы управления реляционными (и не только) базами данных должны удовлетворять двум основным критериям: быть компактными и быстродействующими.
Самое компактное хранение данных — это последовательный несортированный файл, но такая организация данных существенно снижает скорость доступа к данным. Для повышения скорости доступа были введены дополнительные структуры — индексы, в результате чего были увеличены объемы хранимых данных и дополнительные затраты времени на сортировку.
Предлагается совершенно иной подход к физической организации данных — без индексов с разбивкой на блоки и уровни. На уровне 0 хранятся непосредственно данные, на уровнях 1 и выше — характеристики данных на более низком уровне. Как добиться такой однозначности? Всё очень просто. Достаточно всего двух записей в блоках 1 и выше. Одна запись отображает минимальные (min) значения по всем колонкам записей блока, вторая — максимальные (max). В результате избавляемся от ненужных индексов, а значит, нет необходимости заниматься их сортировкой. Каждая колонка таблицы является ключевой. Тем самым увеличивается скорость выборки данных. Чем сложнее запрос, тем быстрее будет происходить выборка. Дополнительно появляется возможность для компрессии блоков данных, имеющих одинаковое количество записей в блоке и одинаковый размер блока, то есть можно улучшить компактность и секретность (при шифровании) хранения данных.
Принципиально важно следующее: в каждой таблице должна быть служебная колонка, в которую операционная система вносит дату и время создания (изменения) записи, что, в конечном счете, приводит к тому, что в базе никогда не будет одинаковых записей.
Табл. 1 поясняет то, о чем сказано выше.
Таблица 1. Структура данных, хранимых в последовательном файле, для супербыстрого доступа без использования индексов
Уровень 0 |
Уровень 1 |
Уровень 2 |
Уровень 3 |
|||
Запись 1 |
Блок 1-1 |
Запись 1-1min Запись 1-1max |
Блок 2-1 |
Запись 2-1min Запись 2-1max |
Блок 3-1 |
Запись 3-1min Запись 3-1max |
… |
||||||
Запись 2N |
||||||
… |
… |
… |
||||
Запись 1 |
Блок 1-N |
Запись 1-Nmin Запись 1-Nmax |
||||
… |
||||||
Запись 2N |
||||||
… |
… |
… |
… |
… |
||
Запись 1 |
Блок 1-1 |
Запись 1-1min Запись 1-1max |
Блок 2-N |
Запись 2-Nmin Запись 2-Nmax |
||
… |
||||||
Запись 2N |
||||||
… |
… |
… |
||||
Запись 1 |
Блок 1-N |
Запись 1-Nmin Запись 1-Nmax |
||||
… |
||||||
Запись 2N |
||||||
… |
… |
… |
… |
… |
… |
… |
Базы могут быть одно- (для представлений) и многотабличными, а таблицы в многотабличных базах — многомерными при использовании данных типа TABLE (таблица в таблице).
Не составляет труда организация хранения массивов в колонках таблиц.
Очень простой становится работа с распределенными базами, размещенными на разных компьютерах с различными операционными системами — достаточно иметь доступ к файлу с возможностью писать и читать файл.
В связи с вышесказанным возникает два вопроса:
- Актуален ли SQL в существующем виде (индексы-то не нужны)?
- Верны ли постулаты реляционной алгебры при такой организации данных?
Идеи, изложенные выше, практически реализованы на языке «C» в СУРБД Start-RTS+ — кроссплатформенной системе управления реляционными базами данных, предназначенной для использования в приложениях (программах), работающих без каких-либо изменений кода для операционных 64-разрядных систем MX-Linux и Windows.
СУРБД Start-RTS+ — это система, в которой использование индексов не требуется, тем не менее, скорость выборки информации гораздо выше, чем в других СУРБД. При усложнении запроса (по большему количеству колонок) скорость выборки только возрастает.
Данные хранятся всегда в одном файле. Это может быть много таблиц — один файл, то есть многотабличная база данных (1) или одна таблица (внешняя) — один файл, то есть однотабличная база данных (2). Таким образом, постоянные данные хранятся в базах типа (1), а производные, получаемые после выполнения реляционных операций, можно хранить в базах типа (2) как временных. В дальнейшем эти базы можно просто удалять за ненадобностью, не изменяя базы типа (1).
Таблицы в базах данных могут быть некомпрессированными или компрессированными.
При задании компрессии объем дискового пространства для хранения данных уменьшается во много раз (как при использовании лучших архиваторов). В этом случае, конечно, незначительно уменьшается скорость выборки. Кроме того, компрессия позволяет засекретить данные.
Высокоскоростная сортировка при выборке данных может быть задана для всех колонок таблицы. Предусмотрено хранение в одной колонке массива однотипных данных и сквозной поиск с учетом значений данных массива.
СУРБД Start-RTS+ работает одновременно со множеством баз данных разной структуры, что позволяет организовать обмен данными между ними.
Возможна параллельная (распределенная) обработка баз данных идентичной структуры, расположенных на разных машинах, линейно повышающая производительность системы.
В настоящее время в СУРБД Start-RTS+ реализованы реляционные операции, приведенные в табл. 2.
Таблица 2. Реляционные операции, реализованные СУРБД Start-RTS+
Create base … |
Создает базу (внешнюю таблицу) данных заданной структуры |
Connect base … |
Подключает ранее созданную базу |
Disconnect base … |
Отключает ранее подключенную базу |
Connect table … |
Подключает ранее созданную внешнюю таблицу |
Disconnect table … |
Отключает ранее подключенную внешнюю таблицу |
Insert rows into base … |
Вставляет в записи таблиц константы, значения переменных, данные из файла или буфера по заданным критериям |
Update rows into base … |
Заменяет записи в таблицах по заданным критериям |
Delete rows from base … |
Удаляет записи из таблиц по заданным критериям |
Select rows from base … |
Выбирает и сортирует записи таблиц по заданным критериям |
inex |
Фраза языка для задания перечня выбираемых колонок |
where |
Фраза языка для задания критериев выборки |
sorting |
Фраза языка для задания критериев сортировки |
На базе Start-RTS+ разработана прикладная технологическая система Смета-RTS для расчета смет в области строительства с нормативными базами регионов России.