|
|
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
Нужен совет по следующей теме: Есть данные о некоторых проектах (проект – это комплекс работ или услуг, имеющий свою стоимость и выполняющийся в ограниченный период времени). По каждому проекту периодически выставляются счета, за время работы проекта может быть множество счетов на оплату. Стоимость проекта может изменяться во время его жизни путём дополнительных соглашений. Максимальная продолжительность проекта – один год. В среднем по каждому проекту выставляются счета с периодичностью в один месяц. Система хранит информацию обо всех проектах и обо всех счетах, выставленных по проектам, а так же о всех дополнительных соглашениях по проектам. Необходимо организовать историю хранения всех проектов (завершённых проектов). Т.е. к системе возможны запросы на получение сведений о завершённых проектах и о выставленных счетах (ретроспективные отчёты). Вижу два варианта организации истории: 1.Каждому проекту присваивается некий статус (завершён, не завершён) и принадлежность проекта истории определяется по этому статусу: активные проекты имеют незавершённый статус, проекты исторические соответственно завершены. Все данные по проектам (завершённым и активным) хранятся в одной таблице 2.Активные проекты и история проектов хранятся в разных таблицах, при завершении проекта информации о нём переносится в таблицу историй проектов. Тут ещё вопрос, как быть со счетами – так же в отдельную историческую таблицу переносить, или хранить в той же, что и счета по активным проектам? Пока я думаю, что лучше второй вариант. В год примерно 60 – 70 проектов, по каждому 10 – 12 счетов в год. Посоветуйте, может, есть лучшие варианты? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 00:11 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
IMHO первый вариант лучше. Поле статуса вообще великая вещь :), позволяет хранить в одной таблице кучу разных данных с похожей структурой.. Плюс обеспечение ссылочной целостности при первом варианте вроде проще.. + случай когда надо вдруг проект "активировать" - опять обратно в др. таблицу тащить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 00:38 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
По-моему первый проще следовательно надежнее, тем более данных не очень много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 06:31 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
По-моему тоже более удобен первый вариант: т.е. делаем таблицу проектов как временной ряд и вносим в эту таблицу все данные по проекту (Код проекта, дата изменения информации о проекте, название, статус и т.д.). При изменении информации о проекте вносим в данную таблицу новую запись - таким образом обеспечиваем сохранение любых изменений происходящих с проектом. Тоже самое делаем со счетами по проектам (в ней будет ссылка на Код проекта). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 09:37 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
а по одному проекту одновременно может действовать два доп соглашения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 15:09 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
TrunovRПри изменении информации о проекте вносим в данную таблицу новую запись - таким образом обеспечиваем сохранение любых изменений происходящих с проектом. Тоже самое делаем со счетами по проектам (в ней будет ссылка на Код проекта). Думал над этим, но потом вовсе отказался, посчитал, что все изменения в проектах будут отражаться в допсоглашениях. gardenman а по одному проекту одновременно может действовать два доп соглашения? По поводу одновременного действия допсоглашений - хороший вопрос, жалко ответа нет на него. Да, ..., думать и думать ещё надо. Спасибо за вопрос :) Но вроде как допсоглашения важны в этом контексте только догда, когда стоимость проекта изменяют (т.к. всё это нужно для отслеживания траты средств по проектам, состав работ, в общем-то, не контролируется), тогда это очень то и не важно. Тут по ходу ещё какая проблема получается: допустим надо показать отчёт по проценту финансирования проекта за прошлый месяц (какой процент был потрачен в прошлом месяце от всей суммы проекта). А стоимость проекта изменили в этом месяце. Т.е. надо помнить какой она была в прошлом месяце!? Получается, что нужен механизм, который бы определял стоимость проекта на конкретную дату (исходя из всех допсоглашений, введённых на эту дату, и изначальных условий). Короче, Не слишком ли я усложнаю, по вашему мнению? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 15:46 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
Тут надо пожалуй подумать с такой точки зрения: 1) Что есть доп соглашение? 2) Иммется ли возможность показать состояние проекта на любую конкретную дату? Т.е. хранить историю это одна позиция. А как правильно ее хранить чтоб реализовать пункт 2? и чтоб при этом не тормозило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2004, 16:33 |
|
||
|
Хранение исторических данных
|
|||
|---|---|---|---|
|
#18+
на первый взгляд - ваша задача один в один совпадает с вопросом - как за 1 селект показать сальдо (приход, расход) по состоянию на любое число. Для этого надо всего лишь употребить конструкцию типа Код: plaintext 1. 2. 3. 4. 5. 6. 7. Такая конструкция может усложняться, путем добавления UNION и расширения кол-ва полей для суммирования . Например, стоимость проекта хранить в списке (как проводка). Тогда, сальдо будет учитывать актуальную стоимость проекта. Приход, расход - под этим здесь можно понимать что угодно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2004, 18:51 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32579990&tid=1546393]: |
0ms |
get settings: |
5ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 340ms |

| 0 / 0 |
