|
|
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Добрый день. Имеется таблица, описывающая древовидную структкуру отделов предприятия. Примерно такого вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Всего уровней уже наблюдается больше 10. Соответственно, таблица: KeyNameParentPathLevelImagek1Министерство правдыk114k2Департамент слуховk1k1/k223k3Департамент телевиденияk1k1/k323k4Департамент радиоk1k1/k423k5Департамент газетk1k1/k523k6Отдел сплетенk2k1/k2/k633k7Отдел сатирыk2k1/k2/k733k8Отдел прозы жизниk2k1/k2/k833k9Отдел зомбированияk3k1/k3/k933k10Отдел концертов ко дню милицииk3k1/k3/k1033k11Отдел телевикторинk3k1/k3/k1133k12Подотдел мата в очередяхk8k1/k2/k8/k1242k13Подотдел рекламыk9k1/k3/k9/k1342k14Подотдел ток-шоуk9k1/k3/k9/k1442k15Подотдел реалити-шоуk9k1/k3/k9/k1542 Аксесс 2007. Главным вопросом является хранение информации в исторической правильности - грубо говоря, если в одном из месяцев поменялась структура (добавились либо удалились отделы, поменялись пути и родители) - то при работе с более ранними "сессиями" - дерево должно описывать именно старую структуру. Данные достаточно часто (но не чаще, чем раз в месяц) меняются. Вопросы и уточнения: 1. Как правильно сохранить структуру для истории - организовав таблицу с историей изменений (тогда попрошу совета по ее форме), либо плодя несколько таблиц с разными структурами для разных периодов? 2. Как лучше всего организовать "сессии" доступа к историческим данным - с помощью формы, предлагающей выбрать дату работы - либо каким-либо другим способом? 3. Что можно почитать по организации иерархических данных? Предварительная часть обсуждения находится здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 16:19 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Dennis S., Я бы честно говоря не стал бы заморачиваться и добавил бы поля "Действует с", "Действует по" и при изменении структуры - сохранял бы новую структуру полностью! Т.е., например с первого февраля подотделы кк13-15 относятся к к8 KeyNameParentPathLevelImageDateBDateEk1Министерство правдыk11401-01-201031-01-2010k2Департамент слуховk1k1/k22301-01-201031-01-2010k3Департамент телевиденияk1k1/k32301-01-201031-01-2010k4Департамент радиоk1k1/k42301-01-201031-01-2010k5Департамент газетk1k1/k52301-01-201031-01-2010k6Отдел сплетенk2k1/k2/k63301-01-201031-01-2010k7Отдел сатирыk2k1/k2/k73301-01-201031-01-2010k8Отдел прозы жизниk2k1/k2/k83301-01-201031-01-2010k9Отдел зомбированияk3k1/k3/k93301-01-201031-01-2010k10Отдел концертов ко дню милицииk3k1/k3/k103301-01-201031-01-2010k11Отдел телевикторинk3k1/k3/k113301-01-201031-01-2010k12Подотдел мата в очередяхk8k1/k2/k8/k124201-01-201031-01-2010k13Подотдел рекламыk9k1/k3/k9/k134201-01-201031-01-2010k14Подотдел ток-шоуk9k1/k3/k9/k144201-01-201031-01-2010k15Подотдел реалити-шоуk9k1/k3/k9/k154201-01-201031-01-2010k1Министерство правдыk11401-02-2010k2Департамент слуховk1k1/k22301-02-2010k3Департамент телевиденияk1k1/k32301-02-2010k4Департамент радиоk1k1/k42301-02-2010k5Департамент газетk1k1/k52301-02-2010k6Отдел сплетенk2k1/k2/k63301-02-2010k7Отдел сатирыk2k1/k2/k73301-02-2010k8Отдел прозы жизниk2k1/k2/k83301-02-2010k9Отдел зомбированияk3k1/k3/k93301-02-2010k10Отдел концертов ко дню милицииk3k1/k3/k103301-02-2010k11Отдел телевикторинk3k1/k3/k113301-02-2010k12Подотдел мата в очередяхk8k1/k2/k8/k124201-02-2010k13Подотдел рекламыk8k1/k3/k8/k134201-02-2010k14Подотдел ток-шоуk8k1/k3/k8/k144201-02-2010k15Подотдел реалити-шоуk8k1/k3/k8/k154201-02-2010 1) Плодить таблицы категорически не рекомендую - т.к. их создание и редактирование структуры - это ручная операция, а у Вас она (операция) будет периодическая. 2) "Сессии" у Вас как будут использоваться? Т.е. если для просмотра пользователю, то понятное дело через форму нужно вводить дату на которую действовала структура.. Если в отчете, то, наверное, происходит Join к таблице, где есть какая-то дата (которая и устанавливает ограничение) 3. Организация у Вас нормальная. А реализацию надо у мастеров Аксесс`а спрашивать )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 16:39 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
lLocustDennis S., Я бы честно говоря не стал бы заморачиваться и добавил бы поля "Действует с", "Действует по" и при изменении структуры - сохранял бы новую структуру полностью! В топку. Теперь добавь подразделение "задним числом" (это наши реалии). К примеру с 25.01.2010 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 16:47 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Andrey.LlLocustDennis S., Я бы честно говоря не стал бы заморачиваться и добавил бы поля "Действует с", "Действует по" и при изменении структуры - сохранял бы новую структуру полностью! В топку. Теперь добавь подразделение "задним числом" (это наши реалии). К примеру с 25.01.2010 Как говорится раскритиковал - предложи свое. А вот мой ответ Чемберлену: KeyNameParentPathLevelImageDateBDateEk1Министерство правдыk11401-01-201024-01-2010k2Департамент слуховk1k1/k22301-01-201024-01-2010k3Департамент телевиденияk1k1/k32301-01-201024-01-2010k4Департамент радиоk1k1/k42301-01-201024-01-2010k5Департамент газетk1k1/k52301-01-201024-01-2010k6Отдел сплетенk2k1/k2/k63301-01-201024-01-2010k7Отдел сатирыk2k1/k2/k73301-01-201024-01-2010k8Отдел прозы жизниk2k1/k2/k83301-01-201024-01-2010k9Отдел зомбированияk3k1/k3/k93301-01-201024-01-2010k10Отдел концертов ко дню милицииk3k1/k3/k103301-01-201024-01-2010k11Отдел телевикторинk3k1/k3/k113301-01-201024-01-2010k12Подотдел мата в очередяхk8k1/k2/k8/k124201-01-201024-01-2010k13Подотдел рекламыk9k1/k3/k9/k134201-01-201024-01-2010k14Подотдел ток-шоуk9k1/k3/k9/k144201-01-201024-01-2010k15Подотдел реалити-шоуk9k1/k3/k9/k154201-01-201024-01-2010k1Министерство правдыk11425-01-201031-01-2010k2Департамент слуховk1k1/k22325-01-201031-01-2010k3Департамент телевиденияk1k1/k32325-01-201031-01-2010k4Департамент радиоk1k1/k42325-01-201031-01-2010k5Департамент газетk1k1/k52325-01-201031-01-2010k6Отдел сплетенk2k1/k2/k63325-01-201031-01-2010k7Отдел сатирыk2k1/k2/k73325-01-201031-01-2010k8Отдел прозы жизниk2k1/k2/k83325-01-201031-01-2010k9Отдел зомбированияk3k1/k3/k93325-01-201031-01-2010k10Отдел концертов ко дню милицииk3k1/k3/k103325-01-201031-01-2010k11Отдел телевикторинk3k1/k3/k113325-01-201031-01-2010k12Подотдел мата в очередяхk8k1/k2/k8/k124225-01-201031-01-2010k13Подотдел рекламыk9k1/k3/k9/k134225-01-201031-01-2010k14Подотдел ток-шоуk9k1/k3/k9/k144225-01-201031-01-2010k15Подотдел реалити-шоуk9k1/k3/k9/k154225-01-201031-01-2010k16ПодПодотдел реалити-шоуk15k1/k3/k9/k15/k165225-01-201031-01-2010k1Министерство правдыk11401-02-2010k2Департамент слуховk1k1/k22301-02-2010k3Департамент телевиденияk1k1/k32301-02-2010k4Департамент радиоk1k1/k42301-02-2010k5Департамент газетk1k1/k52301-02-2010k6Отдел сплетенk2k1/k2/k63301-02-2010k7Отдел сатирыk2k1/k2/k73301-02-2010k8Отдел прозы жизниk2k1/k2/k83301-02-2010k9Отдел зомбированияk3k1/k3/k93301-02-2010k10Отдел концертов ко дню милицииk3k1/k3/k103301-02-2010k11Отдел телевикторинk3k1/k3/k113301-02-2010k12Подотдел мата в очередяхk8k1/k2/k8/k124201-02-2010k13Подотдел рекламыk8k1/k3/k8/k134201-02-2010k14Подотдел ток-шоуk8k1/k3/k8/k144201-02-2010k15Подотдел реалити-шоуk8k1/k3/k8/k154201-02-2010 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 16:59 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Andrey.LТеперь добавь подразделение "задним числом" ( это наши реалии ). К примеру с 25.01.2010Это становиться поговоркой на все случаи. автор--- Почему Вы сделали ПО через жопу? --- Реалии нашего времени.Какие есть препятствия на ведение периода активности подразделений "задним числом" - непонятно. lLocust, +1. Вот только для DateE использовать NULL в качестве "бесконечности" не очень удобно. Лучше какую нибудь константу. Например , '3000-01-01'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 17:36 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Senya_L, Согласен )) А вот препятствия на ведение "задним числом" все же есть.. Andrey.L подразумевал как я буду вводить подраздел во всех пост периодах, следующих за "задним числом". Я же в своем примере ввел в заднем числе - и не ввел в текущем.. И сделал это сознательно! Ведь неизвестно не удалили ли (переименовали/сгруппировали с другим/Расформировали, а потом опять сформировали) предка подраздела в более позднем числе. И оставлять данную ситуацию на откуп программе я бы не стал... И сделал бы это не потому что сложно или лениво, а с довольно определенной целью: Что бы заранее думали что вводят! И если что-то вводят "задним числом", то пусть ручками посмотрят всю историю и убедятся, что все в порядке. И плюс данного метода, что нет мешанины данных в одной таблице. на определенную дату - определенный набор.. (СУБД то не Oracle вестимо, как еще Access обрабатывает иерархию) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 18:23 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
lLocustА вот препятствия на ведение "задним числом" все же есть..Они всегда будут и есть... Если вы напихали дочерних элементов в элемент, который "забыли" вовремя удалить, то проблемы будут в любом случае, но причем тут сама модель? К тому же Andrey.L не предложил ничего взамен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2010, 18:41 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
Dennis S. 1. Как правильно сохранить структуру для истории - организовав таблицу с историей изменений (тогда попрошу совета по ее форме), либо плодя несколько таблиц с разными структурами для разных периодов?Зависит от целей оптимизации - как минимум варианты все в одной таблице или текущие значения в одной таблице, плюс история изменений с одной датой d_change или с двумя датами d_from d_to Каждый из вариантов имеет достоинства и недостатки. Пара аксиом от капитана очевидность хранение дублирующей информации (денормализация) ускоряет (упрощает) запросы, усложняет обновления увеличивая вероятность некорректных результатов запросы с текущей датой будут гораздо чаще исторических Dennis S. 3. Что можно почитать по организации иерархических данных?Поиск в гугле на тему деревья в SQL http://www.osp.ru/pcworld/2007/03/4199032/ http://www.sql.ru/articles/mssql/2005/061904TreesInSQLdatabases.shtml p.s. Аксесс не знаю совсем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2010, 06:29 |
|
||
|
Хранение истории иерархических данных
|
|||
|---|---|---|---|
|
#18+
lLocustА вот препятствия на ведение "задним числом" все же есть.. Andrey.L подразумевал как я буду вводить подраздел во всех пост периодах, следующих за "задним числом". Я же в своем примере ввел в заднем числе - и не ввел в текущем.. И сделал это сознательно! Ведь неизвестно не удалили ли (переименовали/сгруппировали с другим/Расформировали, а потом опять сформировали) предка подраздела в более позднем числе. И оставлять данную ситуацию на откуп программе я бы не стал... И сделал бы это не потому что сложно или лениво, а с довольно определенной целью: Что бы заранее думали что вводят! И если что-то вводят "задним числом", то пусть ручками посмотрят всю историю и убедятся, что все в порядке. Интересно, почему не отдать на откуп программе действия с историчностью? Если отдать на откуп людям, чтобы думали, что вводят, вот здесь Вы с вероятностью, стремящейся к 100%, получите ошибки. А однажды продумать код триггера, ведущего так называемую "ёлку", - дело максимум одного дня со всеми тестами и перекурами/обедами/болтовней с коллегами. Хранение такого вида приведено в одной из книг по Ораклу, да и на данном форуме обсуждалось в теме про хранение остатков, но от СУБД данный подход зависит слабо, главное - чтобы были либо триггеры, либо интерфейс, не позволяющий творить отсебятину и обеспечивающий целостность и непротиворечивость данных. Хранение историчных данных здесь должно исходить из последующих целей использования - если необходимо обеспечить хранение данных на определенный момент времени и возможность обращаться одним запросом ко всей совокупности исторических данных (например, распечатать форму документа, данные для которого должны оставаться неизменными на протяжении всей жизни документа, начиная от момента подписания) - лучшим выходом было бы воспользоваться СУБД, обеспечивающими такое хранение (например, PostgreSQL), хуже (т.к. чрезвычайно затратно) - реализовать собственный движок, т.к. иначе будет очень трудно поддерживать систему в адекватном состоянии, особенно, когда над ней работает много разработчиков или они периодически меняются, у а наихудшим - писать запросы, не реализуя движка, вот здесь огребете тучу проблем. В приведенной во втором посте реализацией существует проблема внешних связей, приводящая к неоднозначности использования данной сущности - иногда необходимо использовать исторические данные, иногда - текущие. Необходимо четко осознавать в каждый момент проектирования взаимодействия, какой тип связи Вам необходим именно здесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2011, 11:12 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=66&tid=1542366]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
292ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 595ms |
| 0 / 0 |
