Системные профили пользователей и записей

Именно системные профили, в том смысле, что принадлежат и создаются они системой, в отличие от UserData. Июль 2004.

Требования:

чтоб обработчикам было удобно доступаться (читать и писать)
thread-safety
чтоб это не в грандиозной степени замедляло общий процесс
в случае потери данных, работоспособность всех прочих частей системы должна сохраняться (это, скорее, требование к пользователям системных профилей — к обработчикам)

Пожелания:

Чтоб в случае потери таблиц базы данных, их можно было восстановить.
Может быть система локов позволит загружать профиль в сессию при входе пользователя и выгружать — при закрытии сессии?
При этом, чтобы профиль был по-прежнему доступен для обработчиков, когда пользователь находится в диалоге с системой. А?

Самый простой вариант

Делаем таблицу, например, acis.sysprof, с двумя столбцами: id и data. В поле id (тип данных: CHAR(200) PRIMARY KEY) мы пишем идентификатор пользователя или записи. В data (тип: BLOB) — Perl Storable’s дамп структуры. Структура — всегда хэш.

Далее, пишем простые функции для доступа: чтения и сохранения данных (всей структуры) для определённого id. Модуль ACIS::Web::SysProf, пространство имён: ACIS::Web.

Далее, пишем вспомогательные функции для:

чтения одного параметра из sysprof;
записи одного параметра и значения в sysprof.

Для обеспечения сохранности данных, периодически делаем архивирование (например, скрипт arpm-backup).

Вызывает сомнения этот элементарный интерфейс. Сомнения: удобство и эффективность (в смысле скорости).

А главное—несколько процессов одновременно не могут доступаться до этих данных.

Вариант номер 2: Куча (heap)

Совершенно другой вариант. Вместо чистой и гладкой таблицы sysprof, где каждой записи или пользователю соответствует одна строка, одна структура, мы можем сделать эту таблицу кучей (a heap).

CREATE TABLE acis.sysprof ( id char(200), param char(40),
data BLOB, PRIMARY KEY ( id, param ) )

Интерфейс:

VALUE = get_sysprof_value ( ID, PARAM );
put_sysprof_value( ID, PARAM, VALUE );
del_sysprof_value( ID, PARAM );

Соответственно:

"SELECT data FROM acis.sysprof WHERE id = ? AND param = ?", ID, PARAM
"REPLACE INTO acis.sysprof VALUES ( ?, ?, ? )", ID, PARAM, VALUE
"DELETE FROM acis.sysprof WHERE id = ? AND param = ?", ID, PARAM

Ну, ещё понадобится функция rename_id( OLD, NEW ). И для человеческого удобства, возможно, get_user_sp_value( PARAM ); put_user_sp_value( PARAM, VALUE ) и get_record_sp_value(), put_record_sp_value().

Недостатки

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

Преимущества

Thread-safety. Относительная безопасность для доступа одновременно несколькими процессами. Относительная потому, что если два разных процесса в один и тот-же момент пишут в один и тот-же параметр, то первая из операций будет похоронена второй.

Иначе говоря, просто придётся очень аккуратно отслеживать кто что может писать и нет способа глобально защититься от нарушения правил.

Для краткости здесь вместо id для записей можно использовать их short-id.

Для порядка, необходимо вести учёт параметров, смысла и форматов их значений.

Разброд и шатание (2004-07-05 00:34)

Видите ли, в разрозненном хранении параметров Системного Профиля и вообще в существовании этого отдельного системного профиля есть проблема. Она происходит от того, что логическая связь между данными userdata и данными из системного профиля очень сильна, а разница — тонка. В некоторых случаях, последовательное, логичное использование системного профиля значительно усложнит всю ситуацию с хранением и извлечением данных (из долговременной памяти).

В ARDB-эшной обработке userdata-файлов (записей) участвует поле static_url. А логически оно более относится к системному профилю. В этом и в некоторых других случаях нет чёткой ясности: логичней хранить параметр в userdata или в системном профиле.

Можно принять за критерий вопрос: является ли поле в прямой власти пользователя? (Может ли пользователь 100%-но контролировать содержимое поля?) Если является (может на 100%), то поле должно храниться в userdata. Но это логично лишь с одной стороны. С точки зрения использования данных, логично и вспомогательную информацию держать тут-же, рядом с первичной.

Отсюда возможен такой путь: разбивать каждую запись на пользовательскую и системную части. В принципе, разумно. Только вот thread-safety…

Короче говоря, сейчас стратегия такая: мы продолжаем использовать userdata для данных, которые могут там храниться, для которых нет необходимости в thread-safe доступе. (Исключение: те, которые усложняют выявление пользовательских изменений, типа last-login-date.)

Что необходимо для Автоматическая поддержка research профайла — выносим в SysProfile. (Собственно, возможно, всё необходимое я уже и вынес…)

Помним об этом сложном компромисе и ищем хорошее и надёжное решение.

(Таким решением могло бы стать хранение всего юзерского профиля в базе данных с чётким атомистическим локинг-контролем… Мама моя!)