Модуль AcedStorage
Содержит типы и классы, предназначенные для организации объектного хранилища данных на локальном компьютере или на файловом сервере с возможностью многопользовательского доступа. Хранение данных на файловом сервере широко использовалось до появления серверов баз данных. В настоящее время для хранения информации почти всегда используется какой-либо сервер БД, контролирующий соблюдение ограничений и целостность данных. Несмотря на очевидные достоинства такого подхода, в некоторых случаях имеет смысл пожертвовать этими возможностями в обмен на компактный формат хранения данных, высокую производительность при выборке и изменении данных, отсутствие необходимости установки серверной части приложения, объектно-ориентированное представление данных. Возложение ответственности за целостность данных на клиентское приложение приводит к некоторому усложнению кода. Тем не менее, наличие готового механизма разрешения коллизий на файловом сервере в значительной мере облегчает эту задачу.
При небольшом объеме хранящихся данных довольно эффективным решением может быть загрузка в память приложения целых таблиц с данным и полная перезапись файлов с данными при их модификации. Недостаток такого способа хранения информации, в отличие от реляционных баз данных, заключается в том, что при изменении даже одного элемента коллекции файл данных приходится переписывать целиком. Чтобы уменьшить значимость этой проблемы можно разбивать большие наборы данных на группы элементов, объединенных по какому-либо признаку, и хранить каждую группу в отдельном файле данных. В памяти следует создать ассоциативный массив, связывающий значение признака с соответствующей коллекцией, представляющей часть общего набора данных. При внесении изменений в одну из таких коллекций нет необходимости перезаписывать другие коллекции того же набора данных.
В реляционных базах данных язык SQL можно рассматривать в качестве посредника между потребителем данных (клиентом) и СУБД (сервером). При подготовке и выполнении сложных запросов возникают две проблемы.
Во-первых, клиент должен сгенерировать текст запроса в виде предложения на языке SQL. Если структура базы данных включает сложные связи между таблицами, конструирование SQL-запросов представляет собой нетривиальную задачу. Во-вторых, на стороне сервера должен быть произведен разбор полученного SQL-предложения, а затем, с учетом метаданных, оптимизация запроса и выполнение кода для фактической манипуляции данными. Эффективное выполнение SQL-запросов представляет собой научную проблему. С другой стороны, можно изначально отказаться от посредника в виде языка SQL при взаимодействии потребителя с хранилищем данных. Безусловно, такой подход может быть применен только ограниченно, в рамках одного приложения или группы проектов. Однако, при правильной организации структуры данных прямое обращение клиентов к данным хранилища может не только повысить производительность, но и, в конечном счете, уменьшить сложность кода, сократить затраты на разработку и сопровождение приложения, чему способствует, в частности, наличие механизма контроля версий данных. При использовании модуля AcedStorage все данные представляются в виде объектов: таблицы – в виде экземпляров класса TSerializableCollection, записи в таблицах – экземплярами класса TSerializableObject, точнее производных от него классов. Для сортировки и поиска записей применяются индексы – объекты типа TDataIndex. К библиотеке AcedUtils прилагается демонстрационный проект – приложение, использующее для хранения данных и одновременного доступа к данным нескольких пользователей классы из модуля AcedStorage. Пример кратко описывается далее в этой статье. Рассмотрим все эти классы подробнее.
