От Сергей
К Василий Т.
Дата 20.07.2005 20:22:33
Рубрики Прочее;

Re: Если можно,

>...какие-нибудь данные.
>Тогда будет над чем подумать...

Выложить даты назначения, должность и наименование части?
С уважением,
Сергей
От Василий Т.
К Сергей (20.07.2005 20:22:33)
Дата 21.07.2005 06:33:32

Re: Если можно,

Доброе время суток!
>>...какие-нибудь данные.
>>Тогда будет над чем подумать...
>
>Выложить даты назначения, должность и наименование части?

Отдельный, но полный, послужной список кого-нибудь из командиров.
Желательно, чтобы это был типовой список, а лучше, наверное, "максимально многостраничный"...
После "прикидки" по этому примеру, можно будет взять несколько подобный списков и попробовать "втиснуть" их в полученную "прикидку".

С уважением, Василий Т. http://ww2doc.50megs.com/Issues.html
От Александр Андреев
К Василий Т. (21.07.2005 06:33:32)
Дата 21.07.2005 08:42:33

Re: Если можно,

>>Выложить даты назначения, должность и наименование части?
>
>Отдельный, но полный, послужной список кого-нибудь из командиров.
>Желательно, чтобы это был типовой список, а лучше, наверное, "максимально многостраничный"...
>После "прикидки" по этому примеру, можно будет взять несколько подобный списков и попробовать "втиснуть" их в полученную "прикидку".

Если Вы хотите соединить базу персоналий с базой истории соединений, то, на мой взгляд, проще реализовать это следующим образом. Таблица истории персоналий должна быть связана с таблицей истории соединений посредством триггеров, вставка или изменение строки в историю персоналий ведет к отработке триггера и добавлению строки в таблицу истории соединений.
Плюсы такого решения: упрощение таблиц и запросов, так как не нужно заботиться о совмещении форматов таблицы персоналий с таблицей истории соединений.
Минусы: проблемы с контролем целостности. Кроме того, для реализации такой базы нужна СУБД уровня Oracle или Postgres.
От Александр Киян
К Александр Андреев (21.07.2005 08:42:33)
Дата 21.07.2005 17:12:50

Re: Если можно,

Приветствую !

>Минусы: проблемы с контролем целостности. Кроме того, для реализации такой базы нужна СУБД уровня Oracle или Postgres.

Пардон, а что имеется в виду под "уровнем" ?
Либо я отстал от жизни, но раньше вышепоименованные СУБД отличались как небо и земля

C уважением
http://rkka.ru
От Александр Андреев
К Александр Киян (21.07.2005 17:12:50)
Дата 25.07.2005 23:04:18

Re: Если можно,



>>Минусы: проблемы с контролем целостности. Кроме того, для реализации такой базы нужна СУБД уровня Oracle или Postgres.
>
>Пардон, а что имеется в виду под "уровнем" ?

Наличие развитого языка хранимых процедур уровня PL SQL.

>Либо я отстал от жизни, но раньше вышепоименованные СУБД отличались как небо и земля

В нынешнем Postgres PL SQL поддерживается. Как один из возможных языков.

>C уважением
> http://rkka.ru
От Александр Киян
К Александр Андреев (25.07.2005 23:04:18)
Дата 26.07.2005 14:43:38

Re: Если можно,

Приветствую !

>>Пардон, а что имеется в виду под "уровнем" ?
>
>Наличие развитого языка хранимых процедур уровня PL SQL.

Насколько я понимаю,хранимые процедуры лишь ускоряют обработку данных.
Планируемые объемы будут достаточно велики, но не критично в плане производительности

C уважением
http://rkka.ru
От Александр Андреев
К Александр Киян (26.07.2005 14:43:38)
Дата 26.07.2005 20:45:44

Re: Если можно,

>Приветствую !

>>>Пардон, а что имеется в виду под "уровнем" ?
>>
>>Наличие развитого языка хранимых процедур уровня PL SQL.
>
>Насколько я понимаю,хранимые процедуры лишь ускоряют обработку данных.
Кроме того, хранимые процедуры позволяют реализовать функциональность, принципиально недостижимую посредством обычных SQL-запросов. Но в рассматриваемом случае важны не хранимые процедуры, а триггеры. Здесь важно то, что в PL SQL - это один язык, более того, из триггеров могут вызываться хранимые процедуры. Задачей триггеров является обеспечение целостности данных. Условно говоря, вставляя в данные по персоналиям данные о том, что некто в такой-то период был командиром такой-то части. мы активируем триггер, который автоматически вставляет в таблицу истории соединений строку о командовании персоны А частью Б. Впоследствии, если данные будут изменены, то другой триггер (отрабатывающий изменения записей в таблице) тоже внесет соответствующие изменения. Триггеры могут отслеживать и те противоречия, которые неизбежно будут появляться при этом. Немножко пошевелив мозгами над грамотной архитектурой базы данных и над триггерами, можно впоследствии значительно облегчить себе работу с запросами и не забивать себе голову контролем целостности и выискиванием противоречий вообще.
>Планируемые объемы будут достаточно велики, но не критично в плане производительности
Я тоже так думаю, поэтому Postgres будет вполне адекватным.
От Сергей
К Василий Т. (21.07.2005 06:33:32)
Дата 21.07.2005 08:38:13

Например

>Отдельный, но полный, послужной список кого-нибудь из командиров.
>Желательно, чтобы это был типовой список, а лучше, наверное, "максимально многостраничный"...
>После "прикидки" по этому примеру, можно будет взять несколько подобный списков и попробовать "втиснуть" их в полученную "прикидку".

https://vif2ne.su/rkka/forum/files/Serg/Afanas_ev.doc

Это послужной список полковника Афанасьева. И только до 1931 года.
А если взять до 45-го, до будет в 2 раза больше.
С уважением,
Сергей
От Василий Т.
К Сергей (21.07.2005 08:38:13)
Дата 21.07.2005 09:25:07

Re: Например

Доброе время суток!
>>Отдельный, но полный, послужной список кого-нибудь из командиров.
>>Желательно, чтобы это был типовой список, а лучше, наверное, "максимально многостраничный"...
>>После "прикидки" по этому примеру, можно будет взять несколько подобный списков и попробовать "втиснуть" их в полученную "прикидку".
>
> https://vif2ne.su/rkka/forum/files/Serg/Afanas_ev.doc

>Это послужной список полковника Афанасьева. И только до 1931 года.
>А если взять до 45-го, до будет в 2 раза больше.

Хмм... Судя по приведенному файлу - или я не понял в чем заключается проблема (я считал, что из-за большого объема информации в послужном списке есть трудности со структуризацией данных, и имел в виду просто текстовую часть послужного списка), или же это у нас взаимно... :o))

Дальше - немного "размышленизмов" для не работавших прежде с БД (извиняюсь, если Вы к таковым не относитесь).

То, что есть в файле уже структуризованно.
Нужно только добавить поле ключа и привязать эту таблицу по нему к основной базе. Если мне память не изменяет, то такая возможность в Access есть. После индексации выборка необходимой информации делается достаточно быстро.
Можно также разбить таблицу на несколько составляющих с одним и тем же ключем.
Например:
1. Индивидуальные характеристики (когда поступил на службу, даты и номера приказов, дата выбытия со службы)
2. Наименование части
3. Наименование должности и категория (если она "намертво" привязана к должности; в противном случае - отправляем категорию тоже в отдельную таблицу)

Основная нагрузка по объему информации будет на первой таблице. Вторая же и третья таблицы будут гораздо меньшими по объему, что позволит еще быстрее локализовать данные в случае необходимости...

С уважением, Василий Т. http://ww2doc.50megs.com/Issues.html