Формат хранения данных в БД

← →
Григорьев Антон © (2004-07-19 16:55) [0]

Такая ситуация: есть несколько десятков некоторых параметров, которые пользователь может менять. Необходимо вести архив изменений: когда и какие параметры были изменены. В качестве БД используется ClientDataSet и локальный файл. Каждый параметр характеризуется уникальным номером. За один сеанс пользователь может изменить любое количество параметров. Нужно, чтобы одна запись в базе данных соответствовала одному сеансу, т.е. содержала информацию обо всех переметрах, изменённых пользователем за сеанс. Но таким образом, чтобы как можно легче было искать изменения конкретного параметра. Пока придумал следующее: в базу записывается строка вида "<N>=<V>{,<N>=<V>}", где <N> - номер параметра, <V> - его значение, фигурные скобки - многократное повтороение при необходимости. Тогда, зная номер параметра, с помощью LIKE можно найти все записи, в которых параметр изменялся, а дальше, с помощью парсинга, узнать его значение. А есть ли другой способ хранить подобную информацию в БД, чтобы её и искать потом можно было?

← →
bushmen © (2004-07-19 17:01) [1]

> А есть ли другой способ хранить подобную информацию в БД, чтобы её и искать потом можно было?

Берешь СУБД. Создаешь 2 таблицы. В одну кидаешь базу, в другую изменения. Связь по уникальному номеру "Один ко Многим". Можно организовать и в файлах, но вряд ли это будет быстрее, чем SQL

← →
HSolo © (2004-07-19 17:07) [2]

Например, так:

Таблица 1 - справочник параметров:
ID записи
Наименование
... что там еще

Таблица 2 - сеансы:
ID записи
Пользователь
... что там еще (начало/конец сеанса...)

Таблица 3 - протокол изменений параметров:
ID сеанса
ID параметра
Значение параметра (можно и старое, и новое)

← →
Digitman © (2004-07-19 17:12) [3]

> Григорьев Антон

храни данные об изменениях в блоб-поле таблицы
за формат хранения данных в этом поле можно взять, например, XML - многие XML-парсеры при загрузке данных хэшируют имена узлов, поэтому поиск узла по имени может существенно сократить время доступа к нему

← →
Григорьев Антон © (2004-07-19 17:20) [4]

> Digitman © (19.07.04 17:12) [3]

Про BLOB"ы думал, но не хватает знаний, как при SQL-запросе осуществить фильрацию по значениям, зписанным в BLOB"е. Такое вообще возможно?

← →
bushmen © (2004-07-19 17:23) [5]

> как при SQL-запросе осуществить фильрацию по значениям,
> зписанным в BLOB"е

А зачем их в Блобе хранить? Так не помещаются?

← →
Григорьев Антон © (2004-07-19 17:30) [6]

> bushmen © (19.07.04 17:23) [5]
>
> А зачем их в Блобе хранить? Так не помещаются?

Digitman [3] посоветовал. Вот я и решил уточнить.

А две таблицы, конечно, можно сделать, но никаких СУБД по ТЗ использовать мне нельзя. Поэтому я и использую ClientDataSet и внешние файлы. Можно, конечно, имитировать связи между таблицами в программе, но это будет уже не то, что в нормальной реляционной СУБД.

← →
Anatoly Podgoretsky © (2004-07-19 17:41) [7]

Не стоит писать кучу <N>=<V>{ лучше на каждую пару отдельная запись, вот тогда сможешб делать LIKE по всей базе

← →
Anatoly Podgoretsky © (2004-07-19 17:43) [8]

Как будешь хранить в файле дело твое, а в таблицу отдельными строками, эта пара и другие параметры, с нормализацией можешь сам решить делать ли и в каком объеме

← →
bushmen © (2004-07-19 17:43) [9]

> но никаких СУБД по ТЗ использовать мне нельзя

Скажи мне, пожалуйста, а что, разве БД Access не удовлетворяет критерию файла? :) Имеется всего один файл с расширением mdb. Или есть еще какие-то ограничения? Напиши

← →
Григорьев Антон © (2004-07-19 17:44) [10]

> Anatoly Podgoretsky © (19.07.04 17:41) [7]
> Не стоит писать кучу <N>=<V>{ лучше на каждую пару отдельная
> запись, вот тогда сможешб делать LIKE по всей базе

Тогда ни строки не нужны, ни LIKE - можно сделать поле "номер параметра" и "новое значение". Но тогда параметры, изменённые во время одной сессии, окажутся разбросанными по разным записям, чего не хотелось бы.

Григорьев Антон © (19.07.04 17:44) [10]
Ну да поле параметр, только не знаю зачем тебе LIKE явно лишнее
Получишь набор по сессии/клиенту/параметру или по любым характерисиками. С моей точки зрения хранить все параметры в одном поле неправильно и неудобно для обработки.

> окажутся разбросанными по разным записям, чего не хотелось бы.

Почему? Выборку по номеру сессии и номеру параметра.

Позволит делать выборки на любой вкус, например узнать какой параметр часто меняют

> Григорьев Антон

действительно. если тебе в дальнейшем потребуются быстрые выборки из этой таблицы, то разумней всего сделать таблицу с такой структурой :

1. ID (счетчик) - первичный ключ
2. ClientID (dword) - вторичный ключ, ид-р клиента
3. SessionId (dword) - вторичный ключ, ид-р клиентской сессии
4. ParamId (dword) - вторичный ключ, ид-р параметра
5. NewParamValue (blob или varchar[] octets) - новое значение параметра (можно хранить значения параметров произв.типа)

Индексы
1. ID - уникальный
2. ClientID
3. SessionId
4. ParamId
5. ClientID, SessionId, ParamId - комбинированный, уникальный

Формат хранения данных в БД Найти похожие ветки