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

SYSDBA в 15:52, 10 апреля 2011

2011-04-10T15:52:31Z

SYSDBA: /* Идеи */

2009-10-11T08:00:56Z

‎Идеи

SYSDBA: /* Идеи */

2009-10-09T18:01:49Z

‎Идеи

SYSDBA: /* Идеи */

2009-10-09T17:55:27Z

‎Идеи

SYSDBA: /* Идеи */

2009-10-09T16:40:27Z

‎Идеи

SYSDBA: /* Идеи */

2009-10-09T13:17:07Z

‎Идеи

SYSDBA: /* Терминология */

2009-10-09T13:15:01Z

‎Терминология

SYSDBA в 13:14, 9 октября 2009

2009-10-09T13:14:30Z

SYSDBA в 12:22, 9 октября 2009

2009-10-09T12:22:16Z

SYSDBA в 19:09, 8 октября 2009

2009-10-08T19:09:00Z

← Предыдущая		Версия 15:52, 10 апреля 2011
Строка 47:		Строка 47:
	## Сохранение прежней версии осуществляем с помощью триггера.		## Сохранение прежней версии осуществляем с помощью триггера.

−	[[Category:Постановка]]	+	[[Category:Постановка-Сделано]]

@@ Строка 24: / Строка 24: @@
 # При сохранении хранища сохраняем/добавляем только измененные объекты отдельными SQL командами.
 ## При удалении объекта хранилища, соответствующую запись удаляем из базы сразу же.
 # Если открыт набор данных бизнес-объекта хранилища, то он синхронизируется с соответствующим объектом хранилища следующим образом:
 ## При удалении записи в наборе данных бизнес-объекта, соответствующий объект удаляется (но, при этом обращения к базе данных не делается. Мы и так удалили соответствующую запись через БО).

@@ Строка 12: / Строка 12: @@
 # Создадим бизнес-объект TgdcStorage для работы с таблицей.
 ## Сооветственно, отпадет необходимость в частных окнах для просмотра хранилища и его элемента. Нас вполне устроит обычная форма просмотра и диалоговое окно бизнес-объекта.
 # Сохраняем неизменной как иерархию классов Хранилища, так и их интерфейсы.
 ## Вводим признак того, что объект хранилища был изменен.
@@ Строка 37: / Строка 40: @@
 ## При обращении к папке/значению пытаемся найти ее по хэшу. Если нет, то ищем стандартным способом. Если нашли, то добавляем в хэш.
 ## При удалении объекта хранилища не забываем удалить ссылку на него в хэше.
 # История изменения значений
 ## Хранить историю изменений имеет смысл только для БЛОБ параметров.
 ## Вводим таблицу GD_STORAGE_HIST со структурой простого бизнес-объекта.
 [[Category:Постановка]]

@@ Строка 5: / Строка 5: @@
 # Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу [[GD_STORAGE_DATA]] для хранения древовидной иерархии хранилищ различных типов и их элементов. Каждый элемент хранилища (папка, параметр) будет отдельной записью в таблице. Каждая запись будет содержать поля для хранения данных параметра, в зависимости от его типа: целочисленное, строковое, БЛОБ, дата и время, число с фиксированной точкой.
 # При апгрейде структуры БД:
 ## Создаются новые метаданные.

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

← Предыдущая		Версия 13:15, 9 октября 2009
Строка 1:		Строка 1:
−	~~=== Терминология ===~~
−
	;Объект хранилища: Относится к существующей иерархии классов, определенных в модуле gsStorage.pas.		;Объект хранилища: Относится к существующей иерархии классов, определенных в модуле gsStorage.pas.
	;Бизнес-объект хранилища: Предназначен для работы с данными хранилища в реляционной таблице. Определен в файле gdcStorage.pas.		;Бизнес-объект хранилища: Предназначен для работы с данными хранилища в реляционной таблице. Определен в файле gdcStorage.pas.

@@ Строка 1: / Строка 1: @@
-Идеи:
+=== Терминология ===
 # Вместо упаковки и записи всего-всего в один большой блоб будем использовать реляционную таблицу для хранения древовидной иерархии.
@@ Строка 25: / Строка 30: @@
 # Настройки
 ## При формировании настройки будем проверять, входят ли в нее объекты хранилища. Если да, то будем заменять их на бизнес-объекты хранилища.
-## РУИДы???
+## При загрузке бизнес-объектов хранилища мы должны выполнять сопоставление в первую очередь по полному пути и только потом по РУИДу.
 # Хэширование...
 [[Category:Постановка]]