Gegevensmodelpatroon voor geschiedenis, maar snel om de meest recente record te vinden

Ik ontwerp een verandering in het gegevensmodel en het viel me op dat er een betere manier moest zijn ...

Ik heb een "logboek" met veel vermeldingen per gelieerde entiteit. Meestal heb ik alleen de meest recente logboekinvoer nodig, maar ik heb nog steeds de oudere gegevens nodig voor auditing, rapportage, enz.

Nu, de gebruikelijke manier waarop ik dit zou doen, is een één-op-veel join maken van bovenliggende entiteit naar de "log" -tabel en vervolgens SQL gebruiken om de meest recente record te vinden.

Maar het kwam bij me op: ik kan het datamodel kiezen. Is hier een beter ontwerppatroon voor?

0

1 antwoord

De fysieke implementatie kan een logboektabel gebruiken die is gepartitioneerd op datum. Kan een rollend venster gebruiken waar de oude partities worden gearchiveerd of samengevat in een soort samenvattende tabel. De toegang tot de tabel kan transparant zijn voor de app, maar toegang met datum verkleint de query naar de juiste partitie (zoekopdrachten op de enkele partitie zijn efficiënter dan in de hele tabel).

Aangezien loggegevens alleen de huidige partitie binnengaan, kunnen oudere partities in de status 'alleen-lezen' worden gezet. Afhankelijk van de rdbms kan dit voordelen hebben, zoals slechts één keer een back-up maken en worden uitgesloten voor toekomstige back-ups, kunnen worden in- en uitgeschakeld op bestandsniveau, enz.

1
toegevoegd