Приведение хранилища к реляционной форме (постановка)
Материал из GedeminWiki
(Различия между версиями)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) |
||
| (не показаны 7 промежуточных версий 1 участника) | |||
| Строка 1: | Строка 1: | ||
| − | + | ;Объект хранилища: Относится к существующей иерархии классов, определенных в модуле gsStorage.pas. | |
| + | ;Бизнес-объект хранилища: Предназначен для работы с данными хранилища в реляционной таблице. Определен в файле gdcStorage.pas. | ||
| − | # Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу для хранения древовидной иерархии. | + | === Идеи === |
| − | # Создадим бизнес-объект для работы с таблицей. Сооветственно, отпадет необходимость в частных окнах для просмотра хранилища и его элемента. Нас вполне устроит обычная форма просмотра и диалоговое окно. | + | |
| + | # Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу [[GD_STORAGE_DATA]] для хранения древовидной иерархии хранилищ различных типов и их элементов. Каждый элемент хранилища (папка, параметр) будет отдельной записью в таблице. Каждая запись будет содержать поля для хранения данных параметра, в зависимости от его типа: целочисленное, строковое, БЛОБ, дата и время, число с фиксированной точкой. | ||
| + | # Полностью отказываемся от кэширования хранилища на локальном диске. | ||
| + | # При апгрейде структуры БД: | ||
| + | ## Создаются новые метаданные. | ||
| + | ## Данные существующих в базе хранилищ пользователя, компании и глобального хранилища перегоняются в новые метаданные. | ||
| + | ## Старые данные защищаются. При попытке их изменения выдается исключение с текстом уведомления о необходимости обновления выполняемого модуля. | ||
| + | # Создадим бизнес-объект TgdcStorage для работы с таблицей. | ||
| + | ## Сооветственно, отпадет необходимость в частных окнах для просмотра хранилища и его элемента. Нас вполне устроит обычная форма просмотра и диалоговое окно бизнес-объекта. | ||
| + | ## Окно свойств папки и окно просмотра БЛОБ данных можно оставить. | ||
| + | ## Отказываемся от поиска по хранилищу. Используем стандартные механизмы бизнес-объекта. | ||
| + | ## Предусматриваем метод бизнес-объекта, который позволит обращаться к объекту хранилища, соответствующему текущей записи из набора данных бизнес-объекта. | ||
# Сохраняем неизменной как иерархию классов Хранилища, так и их интерфейсы. | # Сохраняем неизменной как иерархию классов Хранилища, так и их интерфейсы. | ||
## Вводим признак того, что объект хранилища был изменен. | ## Вводим признак того, что объект хранилища был изменен. | ||
## Добавляем в объект хранилища свойство ИД, по которому будем связывать его с записью в базе. | ## Добавляем в объект хранилища свойство ИД, по которому будем связывать его с записью в базе. | ||
## Для вновь созданных объектов ИД = -1. | ## Для вновь созданных объектов ИД = -1. | ||
| − | # При загрузке хранилища из базы | + | # При загрузке хранилища из базы данные берем из реляционной таблицы и на их основе создаем объекты хранилища. |
## Помечаем их все, как неизмененные. | ## Помечаем их все, как неизмененные. | ||
## Данные БЛОБ объектов грузим только при первом обращении к соответствующим объектам. | ## Данные БЛОБ объектов грузим только при первом обращении к соответствующим объектам. | ||
| − | # При сохранении хранища сохраняем/добавляем только измененные объекты. | + | # При сохранении хранища сохраняем/добавляем только измененные объекты отдельными SQL командами. |
## При удалении объекта хранилища, соответствующую запись удаляем из базы сразу же. | ## При удалении объекта хранилища, соответствующую запись удаляем из базы сразу же. | ||
| − | # Если открыт бизнес- | + | ## Следует учитывать, что изменения могут быть следующими: новый элемент, элемент перемещен в другую папку (изменился парент), элемент поменял имя, поменялось значение параметра. |
| + | # Если открыт набор данных бизнес-объекта хранилища, то он синхронизируется с соответствующим объектом хранилища следующим образом: | ||
## При удалении записи в наборе данных бизнес-объекта, соответствующий объект удаляется (но, при этом обращения к базе данных не делается. Мы и так удалили соответствующую запись через БО). | ## При удалении записи в наборе данных бизнес-объекта, соответствующий объект удаляется (но, при этом обращения к базе данных не делается. Мы и так удалили соответствующую запись через БО). | ||
## При изменении или добавлении записи в набор данных БО, изменяется/добавляется соответствующий объект хранилища. При этом флаг изменения у него не выставляется. | ## При изменении или добавлении записи в набор данных БО, изменяется/добавляется соответствующий объект хранилища. При этом флаг изменения у него не выставляется. | ||
## Сопоставление объекта хранилища и записи в наборе данных БО осуществляется через ИД. | ## Сопоставление объекта хранилища и записи в наборе данных БО осуществляется через ИД. | ||
| − | # При | + | ## При открытии формы просмотра, перед открытием бизнес-объекта, все открытые хранилища записываются в базу. |
| − | + | ## Перед выполнением команды рефреш на форме просмотра все открытые хранилища записываются в базу. | |
| − | ## | + | |
| − | + | ||
# Сохранение и загрузка из потока | # Сохранение и загрузка из потока | ||
| − | ## Формат данных двоичного | + | ## Формат данных двоичного и текстового потоков при сохранении объектов хранилища не изменяется. |
| − | ## При считывании объектов хранилища из двоичного потока они помечаются как измененные и для каждого объекта мы пытаемся найти соответствующую запись в таблице и подставить ее ИД в соответствующее свойство объекта. | + | ## При считывании объектов хранилища из двоичного потока они помечаются как измененные и для каждого объекта мы пытаемся найти соответствующую запись в таблице и подставить ее ИД в соответствующее свойство объекта. Поиск идет по полному пути объекта. |
# Настройки | # Настройки | ||
## При формировании настройки будем проверять, входят ли в нее объекты хранилища. Если да, то будем заменять их на бизнес-объекты хранилища. | ## При формировании настройки будем проверять, входят ли в нее объекты хранилища. Если да, то будем заменять их на бизнес-объекты хранилища. | ||
| − | ## | + | ## При загрузке бизнес-объектов хранилища мы должны выполнять сопоставление в первую очередь по полному пути и только потом по РУИДу. |
| − | # Хэширование... | + | # Хэширование |
| + | ## В класс TgsRootFolder добавляем хэшированный массив. | ||
| + | ## При обращении к папке/значению пытаемся найти ее по хэшу. Если нет, то ищем стандартным способом. Если нашли, то добавляем в хэш. | ||
| + | ## При удалении объекта хранилища не забываем удалить ссылку на него в хэше. | ||
| + | ## При изменении имени объекта или при его перемещении в другую папку не забываем обновить информацию в хэш-таблице. | ||
| + | # История изменения значений | ||
| + | ## Хранить историю изменений имеет смысл только для БЛОБ параметров. | ||
| + | ## Вводим таблицу GD_STORAGE_HIST со структурой простого бизнес-объекта. | ||
| + | ## Сохранение прежней версии осуществляем с помощью триггера. | ||
| − | [[Category:Постановка]] | + | [[Category:Постановка-Сделано]] |
Текущая версия на 18:52, 10 апреля 2011
- Объект хранилища
- Относится к существующей иерархии классов, определенных в модуле gsStorage.pas.
- Бизнес-объект хранилища
- Предназначен для работы с данными хранилища в реляционной таблице. Определен в файле gdcStorage.pas.
[править] Идеи
- Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу GD_STORAGE_DATA для хранения древовидной иерархии хранилищ различных типов и их элементов. Каждый элемент хранилища (папка, параметр) будет отдельной записью в таблице. Каждая запись будет содержать поля для хранения данных параметра, в зависимости от его типа: целочисленное, строковое, БЛОБ, дата и время, число с фиксированной точкой.
- Полностью отказываемся от кэширования хранилища на локальном диске.
- При апгрейде структуры БД:
- Создаются новые метаданные.
- Данные существующих в базе хранилищ пользователя, компании и глобального хранилища перегоняются в новые метаданные.
- Старые данные защищаются. При попытке их изменения выдается исключение с текстом уведомления о необходимости обновления выполняемого модуля.
- Создадим бизнес-объект TgdcStorage для работы с таблицей.
- Сооветственно, отпадет необходимость в частных окнах для просмотра хранилища и его элемента. Нас вполне устроит обычная форма просмотра и диалоговое окно бизнес-объекта.
- Окно свойств папки и окно просмотра БЛОБ данных можно оставить.
- Отказываемся от поиска по хранилищу. Используем стандартные механизмы бизнес-объекта.
- Предусматриваем метод бизнес-объекта, который позволит обращаться к объекту хранилища, соответствующему текущей записи из набора данных бизнес-объекта.
- Сохраняем неизменной как иерархию классов Хранилища, так и их интерфейсы.
- Вводим признак того, что объект хранилища был изменен.
- Добавляем в объект хранилища свойство ИД, по которому будем связывать его с записью в базе.
- Для вновь созданных объектов ИД = -1.
- При загрузке хранилища из базы данные берем из реляционной таблицы и на их основе создаем объекты хранилища.
- Помечаем их все, как неизмененные.
- Данные БЛОБ объектов грузим только при первом обращении к соответствующим объектам.
- При сохранении хранища сохраняем/добавляем только измененные объекты отдельными SQL командами.
- При удалении объекта хранилища, соответствующую запись удаляем из базы сразу же.
- Следует учитывать, что изменения могут быть следующими: новый элемент, элемент перемещен в другую папку (изменился парент), элемент поменял имя, поменялось значение параметра.
- Если открыт набор данных бизнес-объекта хранилища, то он синхронизируется с соответствующим объектом хранилища следующим образом:
- При удалении записи в наборе данных бизнес-объекта, соответствующий объект удаляется (но, при этом обращения к базе данных не делается. Мы и так удалили соответствующую запись через БО).
- При изменении или добавлении записи в набор данных БО, изменяется/добавляется соответствующий объект хранилища. При этом флаг изменения у него не выставляется.
- Сопоставление объекта хранилища и записи в наборе данных БО осуществляется через ИД.
- При открытии формы просмотра, перед открытием бизнес-объекта, все открытые хранилища записываются в базу.
- Перед выполнением команды рефреш на форме просмотра все открытые хранилища записываются в базу.
- Сохранение и загрузка из потока
- Формат данных двоичного и текстового потоков при сохранении объектов хранилища не изменяется.
- При считывании объектов хранилища из двоичного потока они помечаются как измененные и для каждого объекта мы пытаемся найти соответствующую запись в таблице и подставить ее ИД в соответствующее свойство объекта. Поиск идет по полному пути объекта.
- Настройки
- При формировании настройки будем проверять, входят ли в нее объекты хранилища. Если да, то будем заменять их на бизнес-объекты хранилища.
- При загрузке бизнес-объектов хранилища мы должны выполнять сопоставление в первую очередь по полному пути и только потом по РУИДу.
- Хэширование
- В класс TgsRootFolder добавляем хэшированный массив.
- При обращении к папке/значению пытаемся найти ее по хэшу. Если нет, то ищем стандартным способом. Если нашли, то добавляем в хэш.
- При удалении объекта хранилища не забываем удалить ссылку на него в хэше.
- При изменении имени объекта или при его перемещении в другую папку не забываем обновить информацию в хэш-таблице.
- История изменения значений
- Хранить историю изменений имеет смысл только для БЛОБ параметров.
- Вводим таблицу GD_STORAGE_HIST со структурой простого бизнес-объекта.
- Сохранение прежней версии осуществляем с помощью триггера.
