управление на исторически редове в база данни

Първият въпрос трябва да бъде:какво бихте направили с тези данни? Ако нямате ясни бизнес изисквания, не го правете.

Направих нещо подобно и след 3 години работа има около 20% "валидни данни", а останалите са "предишни версии". И това е 10 милиона + 40 милиона записа. През последните три години имахме 2 (две) искания за разследване на историята на промените и двата пъти исканията бяха глупави - записваме времеви печат на промяната на записа и бяхме помолени да проверим дали хората са работили извънредно (след 17:00).

Сега сме заседнали в огромна база данни, която съдържа 80% данни, от които никой не се нуждае.

РЕДАКТИРАНЕ:

Тъй като попитахте за възможни решения, ще опиша какво направихме. Това е малко по-различно от решението, което обмисляте.

1. Всички таблици имат сурогатен първичен ключ.
2. Всички първични ключове се генерират от една поредица. Това работи добре, защото Oracle може да генерира и кешира числа, така че тук няма проблеми с производителността. Използваме ORM и искахме всеки обект в паметта (и съответния запис в базата данни) да има уникален идентификатор
3. Ние използваме ORM и информацията за съпоставяне между таблицата на базата данни и класа е под формата на атрибути.

Ние записваме всички промени в една архивна таблица със следните колони:

• id (сурогатен първичен ключ)
• клеймо за време
• оригинална таблица
• id на оригиналния запис
• потребителски идентификатор
• тип транзакция (вмъкване, актуализиране, изтриване)
• записване на данни като поле varchar2
  • това са действителни данни под формата на двойки име на поле/стойност.

Нещата работят по следния начин:

• ORM има команди за вмъкване/актуализиране и изтриване.
• създадохме един базов клас за всички наши бизнес обекти, който отменя командите за вмъкване/актуализиране и изтриване
  • командите за вмъкване/актуализиране/изтриване създават низ под формата на двойки име на поле/стойност чрез отражение. Кодът търси информация за картографиране и чете името на полето, свързаната стойност и типа на полето. След това създаваме нещо подобно на JSON (добавихме някои модификации). Когато се създаде низ, представящ текущото състояние на обекта, той се вмъква в архивната таблица.
• когато нов или актуализиран обект се записва в таблицата на базата данни, той се записва в неговата целева таблица и в същото време вмъкваме един запис с текуща стойност в архивната таблица.
• когато обектът бъде изтрит, ние го изтриваме от неговата целева таблица и в същото време вмъкваме един запис в архивната таблица, който има тип транзакция ="DELETE"

Професионалист:

• нямаме архивни таблици за всяка таблица в базата данни. Също така не е нужно да се тревожим за актуализиране на архивната таблица, когато схемата се промени.
• пълният архив е отделен от „текущите данни“, така че архивът не налага никакви удари в производителността на базата данни. Поставяме го в отделно таблично пространство на отделен диск и работи добре.
• създадохме 2 форми за преглед на архив:
  • обща програма за преглед, която може да показва архивна таблица според филтъра на архивната таблица. Филтърни данни, които потребителят може да въведе във формуляра (времеви интервал, потребител, ...). Ние показваме всеки запис във формата име на поле/стойност и всяка промяна е цветно кодирана. Потребителите могат да видят всички версии за всеки запис и могат да видят кой и кога е направил промени.
  • програма за преглед на фактури - тази беше сложна, но създадохме формуляр, който показва фактура, много подобен на оригиналния формуляр за въвеждане на фактура, но с някои допълнителни бутони, които могат да показват различни поколения. Създаването на тази форма отне значителни усилия. Формулярът е използван няколко пъти и след това е забравен, защото не е бил необходим в текущия работен процес.
• кодът за създаване на архивни записи се намира в един C# клас. Няма нужда от тригери за всяка таблица в базата данни.
• производителността е много добра. В пиковите моменти системата се използва от около 700-800 потребители. Това е ASP.Net приложение. Както ASP.Net, така и Oracle работят на един двоен XEON с 8 Gb RAM.

Минуси:

• архивният формат с една таблица е по-труден за четене от решението, при което има една архивна таблица за всяка от таблиците с данни.
• търсенето в поле без идентификатор в архивната таблица е трудно - можем да използваме само LIKE оператор върху низ.

Така че отново проверете изискванията за архив . Това не е тривиална задача, но печалбите и употребата могат да бъдат минимални.