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

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

Текущая версия на 18:52, 10 апреля 2011

Объект хранилища
Относится к существующей иерархии классов, определенных в модуле 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. Сохранение прежней версии осуществляем с помощью триггера.
Источник — «https://gsbelarus.com:80/gs/wiki/index.php?title=%D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0_%D0%BA_%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9_%D1%84%D0%BE%D1%80%D0%BC%D0%B5_(%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0)&oldid=4517»
Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты