|
|
|
Ваши мысли по структуре БД ?
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Разрабатывается приложение для обслуживания кучи ключей ЭЦП. (мое первое приложение с полноценной БД ... колупание одновременно 5-6 DBF я не считаю.) Отдельной утилитой могу получить состояние базы открытых ключей на данный момент в таком виде: Имя ключа (в имени зашит тип ключа) дата начала действия ключа дата конца действия ключа дата отмены действия ключа. Код: plaintext 1. 2. 3. 4. Если ключ удален из базы, то и инфы о нем я не получу никакой. Нужно научится отлавливать новые, удаленные, просроченные ключи, контролировать срок до окончания действия ключа и изменения состояний. Что-то вроде: Код: plaintext 1. 2. 3. 4. 5. 6. Статусы: действует ("дней до истечения срока > 0") просрочен ("дней до истечения срока < 0") удален (исчез из принимаемого TXT-файла см. выше) Ну и по выбору ключа нужно посмотреть полную историю ключа. Всё, вроде как ничего ... вполне решаемо для меня. Но! В "светлом будущем" планируется прикрутить к проекту и формирование заявок на добавление/удаление/перегенерацию ключей. Тогда в статусах ключей добавится еще несколько: заказан (подана заявка на добавление, но самого ключа еще нет) на удалении (подана заявка на удаление - ждем обработки) на перегенерации (идентично) Проблема так же в том, что при подаче заявки на добавление я названия ключа не знаю - только тип ... а там уже какой придет - к пользователю его руками привязывать придется (в ключе прописан хозяин его, но я не могу вытащить нормально эту инфу) также изменяется история ключа: добавляются события "подана зявка на ..."/"заявка на ... обработана" и т.д. Вот тут голова начинает пухнуть ... в каком виде эти данные хранить, что стоит предусмотреть, дабы потом можно было добавить "светлое будущее" "малой кровью". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 17:10 |
|
||
|
Ваши мысли по структуре БД ?
|
|||
|---|---|---|---|
|
#18+
Мысли простые - брать PD и рисовать :) я бы заморочился, в первую очередь, с уточнением/прочтением вот этого: при подаче заявки на добавление я названия ключа не знаю - только тип ... а там уже какой придет - к пользователю его руками привязывать придется так как не понятно, добавлять новую запись в ключи при приходе заявки или нет (или я не понял постановки), я бы, наверное сделал _отдельно_ заявки и ключи, поскольку не вижу способа однозначно связать одно с другим в будущем... ну и статусы соответствующие отнести к заявке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 17:29 |
|
||
|
Ваши мысли по структуре БД ?
|
|||
|---|---|---|---|
|
#18+
До чего я додумал за это время (поа думаю - руки ушли на другую пока задачку) Ведем отдельно: время ключей (нчало/конец/отмена) события ключей (добавлен/удален) заявки на ключи(тип заявки/дата подачи/дата погашения) В хранимках .... Файлик с датами затягиваем ... и смотрим, если появился новый ключ, то заносим событие "ключ добавлен". Тут же ставим событие удален ключ. Внесенный ключ будет висеть "бесхозным" - не подтянутым ни к одному юзеру. При добавлении юзеру "бесхозного" ключа ... смотрим на заявки ... если была заявка для этого юзера на новый ключ, то заявку считаем погашеной (ставим дату погашения). Если присписит посмотреть историю ключа, то делаем агромадную вьюшку, в которую соберем данные с этих трех таблиц. Голова уже кругом от этих ключей идет :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 21:34 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34576312&tid=1544475]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
186ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 509ms |

| 0 / 0 |
