Отказ от отговорност: Прочетох всичко, което мога да прочета по темата за моментни снимки и версии както при препълване на стека, така и в интернет. Моето изискване не е проследяване на версии за одитна пътека или моментни снимки на ниво база данни. Прекарах повече от 1 седмица, за да проуча сам и да обмисля възможните варианти. Съжалявам, може да съм пропуснал някои връзки - ако решението на моя проблем вече е обсъждано в друга тема, моля, насочете ме там.
Малко е дълъг; Моля, почакайте ме.
Ето каква е ситуацията: Опитваме се да създадем общ дизайн за съхраняване на моментни снимки на транзакционните данни в нашата транзакционна база данни и също така да поддържаме хронология на ревизиите на референтните данни.
Като част от бизнес процеса, потребителят може да натисне бутон, за да публикува определен обект. За целите на илюстрацията нека кажем, че потребителят може да публикува предложение от доставчика преди началото на преговорите. След това, в различни моменти от време през процеса на договаряне, потребителят може да публикува данните за предложението. Предложението съдържа бюджет, цели за продажби и много други елементи. Когато дадено предложение е моментално заснето, трябва да бъдат направени моментни снимки на всички свързани обекти. Накрая, след преговорите, се подписва договор. В този момент трябва да се създаде пълна моментна снимка на договора. Не всички обекти в договора присъстват в предложението – има много припокриващи се обекти, но има уникални обекти, прикачени към предложението и договора.
Трябва да поддържаме налични както тези публикувани версии, така и най-новите активни версии. Публикуваните версии са достъпни на уебсайт, за да бъдат препращани както от доставчиците, така и от мениджърския екип. Не всички публикувани версии са достъпни на уебсайта, но последното публикувано предложение и последният публикуван договор винаги са достъпни на уебсайта. Този уебсайт също трябва да бъде попълнен от същата база данни.
Освен това финансовият потребител може да реши да направи моментна снимка само на бюджета, а мениджърът по продажбите може да направи моментна снимка на целите за продажби. Така че моментните снимки са налични с множество степени на детайлност.
Също така имаме изискване да проследяваме версиите на основните данни. Бизнес изискване е да се проследяват всички промени в основните основни колони с данни във времето. Например, имаме регионална информация, свързана с целите за продажби. Името на региона може да се промени и ние искаме да проследим тези промени. Да приемем, че по време на предложението името на региона е R1 и е създадена моментна снимка. След това името на региона се променя на R2 и след това се създават 2 други моментни снимки. Искаме да можем да свържем целите за продажби с правилното име на регион в тези моменти от време, а не непременно с последното име на регион.
Имаме известна гъвкавост при моделирането, тъй като имаме както база данни за транзакции, така и база данни за хранилище на данни и можем да решим да съхраняваме част от тази информация или в база данни за транзакции, или в база данни за хранилище на данни.
Ето нашия дизайн. Имаме таблица за публикации, която улавя основна информация за публикуваните данни – кой е публикувал и датата, причината и вида на публикувания обект (предложение или бюджет или цели за продажби).
Ние съхраняваме моментните снимки в същата таблица като оригиналните данни. Така че моментните снимки на предложенията ще се съхраняват с предложенията на живо в таблицата с предложения. Във всяка таблица имаме колона, наречена ИД на публикация, която трябва да бъде публикувана. Тази колона е FK към таблицата Публикация. Ако ИД на публикация е нула, този запис е активната версия.
Разбрах, че публикацията е много дълга. Следователно, вместо да изброявам подробностите на сценария, реших бързо да обобщя съображенията за дизайна в мисловна карта. 
Сега има 2 решения, към които клоним - и двете ще съхраняват моментна снимка на всички данни, независимо дали са се променили или не. Поддържането само на делта при запазване на структурите на таблицата непокътнати би наложило много сложна съхранена процедура, която трябва да се изпълнява при всяко вмъкване/актуализация на който и да е от заснетите обекти. Не искам да тръгвам по този път, тъй като това ще отнеме повече време, а обемите така или иначе не са толкова големи.
Решение 1: Всеки път, когато се публикува обект (като предложение или бюджет), ние ще попълним XML дърво и ще го запазим в базата данни. Само най-новата версия трябва да е налична в уебсайта, а старите версии рядко са необходими. Като се има предвид това, ще се сблъскам ли с голям проблем с производителността поради използването на XML? Използваме SQL Server. Обемите на данните не са големи.
Решение 2: Всички таблици на транзакции ще имат ИД на публикация и референтните данни ще имат начална и крайна дата. Всеки път, когато бъде публикуван обект, бихме направили копие на всички записи на транзакции и бихме поставили идентификатора на публикацията там и бихме копирали всички записи с референтни данни и бихме поставили дата на моментна снимка като крайна дата. Това ще ни позволи да имаме нормални версии за референтни данни извън процеса на публикуване.
Ще имам нужда от мнения от опитни умове тук относно недостатъците на тези 2 подхода и дали има друг по-добър сценарий.
