|
|
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Всем привет! Хочу спросить совета у опытных людей. Именно совет, а не сделать за меня. )) Допустим есть структура Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plaintext 1. 2. 3. 4. 5. 6. На первый взгляд самым простым выходом будет изменить тип связи между Work и Worker на "многие-ко-многим" и в таблице связей хранить период действия той или иной записи справочника Work для Worker. Но хотелось бы посоветоваться с общественностью: кто и как решает такие задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2009, 14:19 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Таблица организаций (работ), таблица физлиц, справочник должностей, таблица кто когда в какой должности работал - id организации, id физлица, id должности, дата с, дата по (может быть открыта если еще не перешел дальше) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2009, 18:56 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Umberto_Eco Что надо делать с совместителями? Вася работает Министерстве и отмывает левые доходы, заработанные в Министерстве через Банк (работает там по совместительству). Что делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2009, 07:24 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Roman S. GolubinUmberto_Eco Что надо делать с совместителями? Вася работает Министерстве и отмывает левые доходы, заработанные в Министерстве через Банк (работает там по совместительству). Что делать?Совмещение нескольких работ - нормальное явление, конечно. Пример взят от фонаря, честно говоря. Учет мест работы - не мой профиль. ) Предыстория такова. Я столкнулся со следующей ситуацией. Функционирует система учета услуг. Отчеты зависят от разнообразных атрибутов сущности "Персона". К примеру "занятость", отсюда и пример вобщем-то. Или социальный статус. Понадобилось сделать отчет повторно спустя более года. За это время некий Вася сменил статус с "безработный", скажем, на "пенсионер". И естественно итог сделанный через год отличался от сделанного неделю назад. Ну, понятное дело протокол изменений просмотрели, причину выяснили. Но меня вопрос хронологической согласованности заинтересовал. Есть и другие ситуации. Человек меняет фамилию. Ему оказываются некие услуги. Требуется знать, что на момент оказания услуги1 он был Вася, а на момент оказания услуги2 стал Кондратием. Как-то так. Решение для отдельных ситуаций придумать несложно. Но подозреваю, что требуется системный подход к разработке архитектуры БД. То, что предложил П-Л я говорил в последнем абзаце первого сообщения. Интересен чужой опыт. Кто, как и почему. ) ЗЫ. Читаю Дейта на сей предмет, но что то пока тяжело дается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2009, 13:07 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Developing Time-Oriented Database Applications in SQL RICHARD T. SNODGRASS Contents Foreword by Jim Gray vii Foreword by Jim Melton ix Preface xvii 1 Introduction 1 1.1 A Triad of Triples 2 1.2 The SQL Standard 4 1.3 Conventions 5 1.4 Implementation Considerations 7 1.5 Readings 8 2 Fundamental Concepts 11 2.1 Valid-Time State Tables 12 2.2 Transaction-Time State Tables 18 2.3 Bitemporal Tables 20 2.4 Summary 22 2.5 Readings 23 3 Instants and Intervals 25 3.1 Instants 26 3.2 Intervals 30 x i i CONTENTS 3.3 Predicates 33 3.4 Constructors 36 3.5 Implementation Considerations 42 3.6 The Year 2000 Problem* 63 3.7 Subtleties* 74 3.8 Implementation Considerations* 83 3.9 Summary 84 3.10 Readings 85 4 Periods 89 4.1 Literals 90 4.2 Predicates 90 4.3 Constructors 93 4.4 Implementation Considerations 97 4.5 Summary 108 4.6 Readings 108 5 Dening State Tables 111 5.1 Initial Schema 112 5.2 Adding History 113 5.3 Temporal Keys 117 5.4 Handling Now 119 5.5 Uniqueness Reexamined 121 5.6 Referential Integrity 126 5.7 Constraint Attributes* 131 5.8 Implementation Considerations 132 5.9 Summary 139 5.10 Readings 140 6 Querying State Tables 143 6.1 Extracting the Current State 143 6.2 Extracting Prior States 145 CONTENTS x i i i 6.3 Sequenced Queries 145 6.4 Nonsequenced Variants 156 6.5 Eliminating Duplicates 158 6.6 Implementation Considerations 169 6.7 Summary 173 6.8 Readings 174 7 Modifying State Tables 177 7.1 Current Modications 177 7.2 Sequenced Modications 188 7.3 Nonsequenced Modications 197 7.4 Modications That Mention Other Tables* 198 7.5 Temporal Partitioning* 206 7.6 Implementation Considerations 213 7.7 Summary 215 7.8 Readings 216 8 Retaining a Tracking Log 219 8.1 Dening the Tracking Log 220 8.2 Queries 222 8.3 Modications 229 8.4 Permitting Insertions 230 8.5 Backlogs 233 8.6 Using After-Images Consistently 235 8.7 Transaction Semantics* 240 8.8 Renements* 243 8.9 Implementation Considerations 244 8.10 Summary 248 8.11 Readings 250 9 Transaction-Time State Tables 253 9.1 Denition 254 9.2 Maintenance 255 x i v CONTENTS 9.3 Queries 259 9.4 Temporal Partitioning* 262 9.5 Vacuuming* 268 9.6 Implementation Considerations 272 9.7 Summary 273 9.8 Readings 275 10 Bitemporal Tables 277 10.1 Denition 278 10.2 Modications 282 10.3 Queries 307 10.4 Integrity Constraints 323 10.5 Temporal Partitioning* 329 10.6 Vacuuming* 337 10.7 Implementation Considerations 339 10.8 Summary 339 10.9 Readings 340 11 Temporal Database Design 343 11.1 Properly Sequencing the Design 343 11.2 Conceptual Design 345 11.3 Logical Design 355 11.4 Physical Design 375 11.5 Advanced Design Aspects* 377 11.6 Benets 382 11.7 Application Development 383 11.8 Implementation Considerations 396 11.9 Summary 397 11.10 Readings 397 CONTENTS xv 12 Language Directions 401 12.1 SQL-92 401 12.2 SQL-92 Limitations 401 12.3 SQL3 402 12.4 Periods 403 12.5 Dening Valid-Time State Tables 406 12.6 Querying State Tables 411 12.7 Modifying State Tables 416 12.8 Retaining a Tracking Log 421 12.9 Transaction-Time State Tables 426 12.10 Bitemporal Tables 427 12.11 Capstone Case 437 12.12 Migration 446 12.13 Additional Constructs of SQL3* 455 12.14 Implementation Considerations 457 12.15 Summary 460 12.16 Readings 465 13 Prospects 469 Glossary 471 Bibliography 479 Author Index 485 Subject Index 487 About the Author 502 About the CD-ROM 503 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2009, 11:37 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Федоров, аноним, Спасибо большое. Попробую разобраться с творением Снодграсса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2009, 17:43 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
В двух словах - если контроль над приложением полный (новое приложение) то 1 в таблицу добавляется пара полей dfrom, dto, плюс триггеры отслеживающие дыры/пересечения. 2 Текущую дату можно делать либо null (красившее) либо волшебная дата в будущем типа 01-01-9999 (проще в реализации). 3 во ВСЕ запросы вводится условие :query_date between dfrom and dto (или dfrom<=:query_date and :query_date<dto) 4 Одна из дат (лучше dto) добавляется в индексы Для существующего приложения условие 3 как правило самое трудновыполнимое, поэтому применяют другой подход. 1 вводят дополнительную таблицу - история изменений параметра Х со всеми причиндалами из пунктов 1 - 4 выше 2 пишут триггер чтобы сохранял изменения параметра Х 3 в исторических запросах параметр Х берут из таблицы истории, а не базовой таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2009, 22:30 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
SERG1257, После беглого прочтения Снодграсса больше склоняюсь к таблицам состояния, т.е. вынести изменяющиеся во времени атрибуты сущности в отдельную таблицу. Единственное, что смущает, что на каждый "чих" в виде изменения одного атрибута необходимо добавлять новую запись. Повторения много. Может EAV задействовать? Хотя... имеются опасения, что найдутся какие-нибудь грабли. Особенно учитывая, что с EAV для больших таблиц не работал. P.S. А изменением логики существующего приложения проблем больших не ожидается, потому что все запросы через хранимки проводятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2009, 22:54 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Umberto_Eco вынести изменяющиеся во времени атрибуты сущности в отдельную таблицу.То бишь пойти по первому пути добавив две даты. Umberto_Eco что на каждый "чих" в виде изменения одного атрибута необходимо добавлять новую запись. Зато читается быстро, а место на диске нынче дешево. Umberto_Eco Повторения много. Для таких быстроменяющихся атрибутов можно воспользоваться вторым путем. Umberto_Eco Может EAV задействовать? Хотя... имеются опасения, что найдутся какие-нибудь грабли.Грабля там одна, но большая - производительность просаживается капитально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2009, 00:14 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
SERG1257, Благодарю. Попробую описанный мною выше подход. Будет время - отпишусь как это выглядит на схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2009, 09:17 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
вот Шаблон: Периодические сведения Здесь персона - измерение ее состояние - ресурс Персоны и состояния естественно отдельные таблицы С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2009, 09:42 |
|
||
|
Хронологичность данных
|
|||
|---|---|---|---|
|
#18+
Как и обещал делюсь "успехами" в проектировании time-oriented баз данных. Во-первых, повторно большое спасибо за ссылку на труд Снодграсса мемберу Федорову. Книга дала много пищи для ума. Английский непрост (лично для меня), но форма изложение очень даже импонирует. После более вдумчивого прочтения. Из трех подходов к проектированию мои изначальные цели решаемы полностью, пожалуй, только с использованием bitemporal tables, совмещающего версионирование во времени и протоколирование изменений. Но этот подход сложнее. Пока решил остановиться на valid-time state tables. Не претендую на оригинальность. Уверен эта тема обсуждалась не раз. Ссылка Naf подтверждает, что тема не нова. Но указанный топик слишком абстрактен и слабо аргументирован на практике. Приведу образчик кода (T-SQL, MSSQL2008) Фрагмент кода Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. К чему это я? Предлагаю свою тему для обсуждения вопросов по разработке time-oriented баз данных. Начнем? Вопросы: 1) Безопасна ли схема изменения атрибутов сущности, приведенная выше в случае MSSQL в режиме "чистого" версионника? 2) При размышлениях пришел к предварительному выводу, что среди СУБД "верисонники" не смогут гарантировать непересекаемость интервалов действия (прошу прощения за кустарную терминологию). Это при том, что мне версионники нравились больше. Прав ли я? 3) Надежные способы обеспечения непересекаемости интервалов действия без поддержки декларативного объявления (таковых в SQL не имеется пока)? 4) В работе Снодграсса используется проверка на CHECK-ограничениях. Надежна ли она? Выскажите свои соображения по этому поводу, пожалуйста. Интересно обменяться мнением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2010, 16:39 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36336945&tid=1542886]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
282ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 623ms |

| 0 / 0 |
