Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

Digitman (2004-07-20 08:19:00) [1]

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

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

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 - комбинированный, уникальный

Anatoly Podgoretsky (2004-07-19 19:58:00) [2]
Позволит делать выборки на любой вкус, например узнать какой параметр часто меняют

bushmen (2004-07-19 17:57:00) [3]
> окажутся разбросанными по разным записям, чего не хотелось бы.

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

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

Григорьев Антон (2004-07-19 17:44:00) [5]

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

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

Anatoly Podgoretsky (2004-07-19 17:43:00) [6]
Как будешь хранить в файле дело твое, а в таблицу отдельными строками, эта пара и другие параметры, с нормализацией можешь сам решить делать ли и в каком объеме

bushmen (2004-07-19 17:43:00) [7]
> но никаких СУБД по ТЗ использовать мне нельзя

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

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

Григорьев Антон (2004-07-19 17:30:00) [9]

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

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

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

bushmen (2004-07-19 17:23:00) [10]
> как при SQL-запросе осуществить фильрацию по значениям,
> зписанным в BLOB'е

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

Григорьев Антон (2004-07-19 17:20:00) [11]

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

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

Digitman (2004-07-19 17:12:00) [12]

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

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

HSolo (2004-07-19 17:07:00) [13]
Например, так:

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

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

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

bushmen (2004-07-19 17:01:00) [14]
> А есть ли другой способ хранить подобную информацию в БД, чтобы её и искать потом можно было?

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »