Приведение хранилища к реляционной форме (постановка)

Объект хранилища

Относится к существующей иерархии классов, определенных в модуле gsStorage.pas.

Бизнес-объект хранилища

Предназначен для работы с данными хранилища в реляционной таблице. Определен в файле gdcStorage.pas.

Идеи

1. Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу GD_STORAGE_DATA для хранения древовидной иерархии хранилищ различных типов и их элементов. Каждый элемент хранилища (папка, параметр) будет отдельной записью в таблице. Каждая запись будет содержать поля для хранения данных параметра, в зависимости от его типа: целочисленное, строковое, БЛОБ, дата и время, число с фиксированной точкой.
2. Полностью отказываемся от кэширования хранилища на локальном диске.
3. При апгрейде структуры БД:
   1. Создаются новые метаданные.
   2. Данные существующих в базе хранилищ пользователя, компании и глобального хранилища перегоняются в новые метаданные.
   3. Старые данные защищаются. При попытке их изменения выдается исключение с текстом уведомления о необходимости обновления выполняемого модуля.
4. Создадим бизнес-объект TgdcStorage для работы с таблицей.
   1. Сооветственно, отпадет необходимость в частных окнах для просмотра хранилища и его элемента. Нас вполне устроит обычная форма просмотра и диалоговое окно бизнес-объекта.
   2. Окно свойств папки и окно просмотра БЛОБ данных можно оставить.
   3. Отказываемся от поиска по хранилищу. Используем стандартные механизмы бизнес-объекта.
   4. Предусматриваем метод бизнес-объекта, который позволит обращаться к объекту хранилища, соответствующему текущей записи из набора данных бизнес-объекта.
5. Сохраняем неизменной как иерархию классов Хранилища, так и их интерфейсы.
   1. Вводим признак того, что объект хранилища был изменен.
   2. Добавляем в объект хранилища свойство ИД, по которому будем связывать его с записью в базе.
   3. Для вновь созданных объектов ИД = -1.
6. При загрузке хранилища из базы данные берем из реляционной таблицы и на их основе создаем объекты хранилища.
   1. Помечаем их все, как неизмененные.
   2. Данные БЛОБ объектов грузим только при первом обращении к соответствующим объектам.
7. При сохранении хранища сохраняем/добавляем только измененные объекты отдельными SQL командами.
   1. При удалении объекта хранилища, соответствующую запись удаляем из базы сразу же.
   2. Следует учитывать, что изменения могут быть следующими: новый элемент, элемент перемещен в другую папку (изменился парент), элемент поменял имя, поменялось значение параметра.
8. Если открыт набор данных бизнес-объекта хранилища, то он синхронизируется с соответствующим объектом хранилища следующим образом:
   1. При удалении записи в наборе данных бизнес-объекта, соответствующий объект удаляется (но, при этом обращения к базе данных не делается. Мы и так удалили соответствующую запись через БО).
   2. При изменении или добавлении записи в набор данных БО, изменяется/добавляется соответствующий объект хранилища. При этом флаг изменения у него не выставляется.
   3. Сопоставление объекта хранилища и записи в наборе данных БО осуществляется через ИД.
   4. При открытии формы просмотра, перед открытием бизнес-объекта, все открытые хранилища записываются в базу.
   5. Перед выполнением команды рефреш на форме просмотра все открытые хранилища записываются в базу.
9. Сохранение и загрузка из потока
   1. Формат данных двоичного и текстового потоков при сохранении объектов хранилища не изменяется.
   2. При считывании объектов хранилища из двоичного потока они помечаются как измененные и для каждого объекта мы пытаемся найти соответствующую запись в таблице и подставить ее ИД в соответствующее свойство объекта. Поиск идет по полному пути объекта.
10. Настройки
    1. При формировании настройки будем проверять, входят ли в нее объекты хранилища. Если да, то будем заменять их на бизнес-объекты хранилища.
    2. При загрузке бизнес-объектов хранилища мы должны выполнять сопоставление в первую очередь по полному пути и только потом по РУИДу.
11. Хэширование
    1. В класс TgsRootFolder добавляем хэшированный массив.
    2. При обращении к папке/значению пытаемся найти ее по хэшу. Если нет, то ищем стандартным способом. Если нашли, то добавляем в хэш.
    3. При удалении объекта хранилища не забываем удалить ссылку на него в хэше.
    4. При изменении имени объекта или при его перемещении в другую папку не забываем обновить информацию в хэш-таблице.
12. История изменения значений
    1. Хранить историю изменений имеет смысл только для БЛОБ параметров.
    2. Вводим таблицу GD_STORAGE_HIST со структурой простого бизнес-объекта.
    3. Сохранение прежней версии осуществляем с помощью триггера.