Temporale Tabellen
- Ersteller Martinha
- Erstellt am
Werbung:
dabadepdu
Datenbank-Guru
- Beiträge
- 1.896
Nein, temporäre Tabellen im Sinne einer deklarativen Erzeugung als temporäre Tabelle musste ich bis jetzt kaum einsetzen.
Die Frage ist, wofür man sowas braucht, was man damit erreichen will oder kann. Und was Du damit erreichen willst.
Dass Du sie für "viele Änderungen" verwendest, plus einer Historie klingt in meinen Ohren widersprüchlich.
Wenn eine temporäre Tabelle für Dich mehr ist oder etwas anderes, als explizit in einer laufenden Session eine temporäre Tabelle anzulegen, die beim Beenden der Sitzung automatisch wieder verschwindet, dann würde ich mich für die Diskussion Deiner Ziele einfach wieder von dem Begriff "temporär" verabschieden.
Reguläre, temporäre Tabellen sind m.E. hauptsächlich ein Workaround, mit dem Dinge erreicht werden sollen, die man aus Unwissen oder aufgrund fehlender Datenbankfähigkeiten (Fähigkeiten, Funktionen der Datenbank) nicht anders hinbekommt.
-Temporäre Tabellen verbrauchen (kurzzeitig) Platz,
- Sie veralten ab dem Moment ihrer Erzeugung
- Sie sind zunächst mal wegen ihres temporären Charakters eher das Kastrat einer Tabelle (jenseits des temporären Daseins) statt einer vollwertigen Tabelle.
- Daraus ergibt sich, dass sie "langsamer" sind als eine Standardtabelle.
- Sie sind adhoc intransparent, sowohl von der Natur her grundsätzlich, als auch für alle Serverprozesse drumherum
- Sie sind besonders nach ihrem Verschwinden intransparent, ebenso alle Daten und Prozesse, deren Inhalte auf sie aufbauen.
Für viele dieser Aspekte gibt es wiederum Ansatzpunkte, sie zu vermeiden oder zu mildern. Wie gesagt, die Frage ist, was man tatsächlich erreichen möchte und ob sie tatsächlich gemäß ihrer Natur eingesetzt werden. Man muss keine Probleme umgehen, die durch den Einsatz falscher Werkzeuge oder auch nur missverständlicher Begriffe auftreten.
Die Frage ist, wofür man sowas braucht, was man damit erreichen will oder kann. Und was Du damit erreichen willst.
Dass Du sie für "viele Änderungen" verwendest, plus einer Historie klingt in meinen Ohren widersprüchlich.
Wenn eine temporäre Tabelle für Dich mehr ist oder etwas anderes, als explizit in einer laufenden Session eine temporäre Tabelle anzulegen, die beim Beenden der Sitzung automatisch wieder verschwindet, dann würde ich mich für die Diskussion Deiner Ziele einfach wieder von dem Begriff "temporär" verabschieden.
Reguläre, temporäre Tabellen sind m.E. hauptsächlich ein Workaround, mit dem Dinge erreicht werden sollen, die man aus Unwissen oder aufgrund fehlender Datenbankfähigkeiten (Fähigkeiten, Funktionen der Datenbank) nicht anders hinbekommt.
-Temporäre Tabellen verbrauchen (kurzzeitig) Platz,
- Sie veralten ab dem Moment ihrer Erzeugung
- Sie sind zunächst mal wegen ihres temporären Charakters eher das Kastrat einer Tabelle (jenseits des temporären Daseins) statt einer vollwertigen Tabelle.
- Daraus ergibt sich, dass sie "langsamer" sind als eine Standardtabelle.
- Sie sind adhoc intransparent, sowohl von der Natur her grundsätzlich, als auch für alle Serverprozesse drumherum
- Sie sind besonders nach ihrem Verschwinden intransparent, ebenso alle Daten und Prozesse, deren Inhalte auf sie aufbauen.
Für viele dieser Aspekte gibt es wiederum Ansatzpunkte, sie zu vermeiden oder zu mildern. Wie gesagt, die Frage ist, was man tatsächlich erreichen möchte und ob sie tatsächlich gemäß ihrer Natur eingesetzt werden. Man muss keine Probleme umgehen, die durch den Einsatz falscher Werkzeuge oder auch nur missverständlicher Begriffe auftreten.
Martinha
Fleissiger Benutzer
- Beiträge
- 73
Hi,
sie sind nicht temporär, sondern temporal, also historische Tabellen, d.h. bei jeder Änderung wird ein Satz in einer Spiegeltabelle angelegt. Der originale Satz und die historischen haben jeweils zwei datum-Zeit Felder, die anzeigen von wann bis wann sie gültig waren.
Einmal definiert, läuft das von alleine...
Auch in komplexeren Beziehungsgeflechten läuft das wunderbar.
Die Abfragemöglichkeiten sind umfangreich.
Martin
sie sind nicht temporär, sondern temporal, also historische Tabellen, d.h. bei jeder Änderung wird ein Satz in einer Spiegeltabelle angelegt. Der originale Satz und die historischen haben jeweils zwei datum-Zeit Felder, die anzeigen von wann bis wann sie gültig waren.
Einmal definiert, läuft das von alleine...
Temporale Tabellen - SQL Server
Temporale Tabellen mit Versionsverwaltung durch das System bieten integrierte Unterstützung für das Bereitstellen von Informationen über die zu jedem Zeitpunkt in der Tabelle gespeicherten Daten.
learn.microsoft.com
Auch in komplexeren Beziehungsgeflechten läuft das wunderbar.
Die Abfragemöglichkeiten sind umfangreich.
Martin
BerndB
Datenbank-Guru
- Beiträge
- 502
Oh NOOOOOOOO, kein Workaround !!
Temporäre Tabellen haben schon ihre Vorteile. Wenn z.B. ein User Daten importieren kann (CSV,Excel oder jedes andere Format) und erst nach dem Import festgestellt werden kann ob diese valide sind oder man anzeigen möchte was sich dadurch ändert lohnt sich ein Temp. Table.
Natürlich geht das auch mit einer normalen Import Tabelle, jedoch wenn mehrere oder alle User dies gleichzeitig machen können kommt der Vorteil, denn für jede wird eine eigene Tabelle mit dem gleichen Namen (nach aussen) angelegt, die nur für dich ist und andere Queryies sehen diese auch nicht.
Gruß
Bernd
Martinha
Fleissiger Benutzer
- Beiträge
- 73
Hi,
temporäre Tabellen waren nicht meine Frage, sondern temporale Tabellen, also historische Datenhaltung.
Ich speichere temporäre Tabellen in dem Access-Frontend. Würde ich sie im Backend speichern, müsste ich die Userid mit in die Spalten aufhnehmen...kann man machen...
Martin
temporäre Tabellen waren nicht meine Frage, sondern temporale Tabellen, also historische Datenhaltung.
Ich speichere temporäre Tabellen in dem Access-Frontend. Würde ich sie im Backend speichern, müsste ich die Userid mit in die Spalten aufhnehmen...kann man machen...
Martin
ukulele
Datenbank-Guru
- Beiträge
- 5.359
Interessantes Prinzip, hatte ich noch nicht mit zu tun. Im Prinzip greife ich auf solche Daten zu aber auf eine eher klassische Weise mit Joins. Die Tabellen scheinen auch auf klassischen Wege entstanden zu sein, daher werde ich wohl keine Komfort- oder Performance Vorteile nutzbar machen können.
Allgemein scheint mir das vor allem dann sinnvoll, wenn sich der komplette Datensatz ändert oder es einfach gehalten werden soll. Bei großen Tabellen mit kleinen Änderungen ist das natürlich viel Overhead an Speicherplatz. In meinem CRM arbeite ich mit Log-Triggern die pro Attribut eine Zeile schreiben, nicht den ganzen Datensatz mit nehmen. Daraus muss ich aber auch keinen alten Zustand zum Zeitpunkt X ermitteln, das wäre was anderes.
Allgemein scheint mir das vor allem dann sinnvoll, wenn sich der komplette Datensatz ändert oder es einfach gehalten werden soll. Bei großen Tabellen mit kleinen Änderungen ist das natürlich viel Overhead an Speicherplatz. In meinem CRM arbeite ich mit Log-Triggern die pro Attribut eine Zeile schreiben, nicht den ganzen Datensatz mit nehmen. Daraus muss ich aber auch keinen alten Zustand zum Zeitpunkt X ermitteln, das wäre was anderes.
Hier ist ein kleines Beispiel wie das im SQL Standard definiert ist:
Gibt es mittlerweile in relativ vielen Datenbanken (nur Postgres leider noch nicht
)
Martinha
Fleissiger Benutzer
- Beiträge
- 73
Ich habe ja nur eine sehr kleine DB und es kappt prima.
Ich habe mir da einige Abfragen gebastelt und kann jetzt z.B. den Werdegang eines Schülers durch die einzelnen Kurse nachvollziehen.
Die Daten hole ich mir über STP, weil es die Abfragen so in ACCESS nicht gibt.
Wenn jemand mehr wissen möchte, bitte melden.
Ich habe mir da einige Abfragen gebastelt und kann jetzt z.B. den Werdegang eines Schülers durch die einzelnen Kurse nachvollziehen.
Die Daten hole ich mir über STP, weil es die Abfragen so in ACCESS nicht gibt.
Wenn jemand mehr wissen möchte, bitte melden.
Martinha
Fleissiger Benutzer
- Beiträge
- 73
Sicher, ich bin aber immer dafür etwas nur selbst zu machen, wenn es etwas nicht gibt oder die angebotenen Lösung unbefriedigend ist. Aber die Abfragemöglichkeiten mit "as of" oder "contains in" sind schon klasse. Natürlich würde man das auch irgendwie selbst hinkriegen, aber für meine Zwecke passt das gut. Ich wollte ja nur mal anregen, sich das mal anzusehen.
Ich habe mehrere verknüpfte Tabellen und da dann die richtigen History Werte zu ermitteln, ist schon nicht ohne.
Es ist auch gedacht für Big Data, die man dann mit ausgefuchsten Methoden auswertet.
Literatur gibt es genug, selbst Chatgpt kennt temporale Tabellen.
Ich habe mehrere verknüpfte Tabellen und da dann die richtigen History Werte zu ermitteln, ist schon nicht ohne.
Es ist auch gedacht für Big Data, die man dann mit ausgefuchsten Methoden auswertet.
Literatur gibt es genug, selbst Chatgpt kennt temporale Tabellen.
Temporale Tabellen nehmen dir schon viel ab. Es mit einfach nur einer zweiten Tabelle dazunehmen ist es ja nicht getan.
Btw. Das Thema hatten wir schon im Forum und ich hatte eine Extension für Postgresql gepostet:
Für Historische Daten gibt es bei MSSQL Historale Tabellen:
Bei anderen Datenbanksystemen muss man das ggf. nachbauen.
www.linkedin.com
EDIT:
Postgresql hat eine Extension dafür:
github.com
Temporal tables - SQL Server
System-versioned temporal tables bring built-in support for providing information about data stored in the table at any point in time.
learn.microsoft.com
Bei anderen Datenbanksystemen muss man das ggf. nachbauen.
Historical Data Tracking in PostgreSQL - Part 1: Historical Table and Triggers
Introduction to Historical Data Tracking in PostgreSQL Historical data tracking, also known as #historification, plays a crucial role in maintaining a comprehensive record of changes made to data over time. This process allows us to access previous versions of data and analyze its evolution, providi
EDIT:
Postgresql hat eine Extension dafür:
GitHub - arkhipov/temporal_tables: Temporal Tables PostgreSQL Extension
Temporal Tables PostgreSQL Extension. Contribute to arkhipov/temporal_tables development by creating an account on GitHub.
github.com
Martinha
Fleissiger Benutzer
- Beiträge
- 73
Hi,
Ukulele befürchtet, das bei seinen großen Datenmengen das ganze ein oversized Problem wird. Das sehe ich bei großen DB's durchaus auch so... es gibt da aber Möglichkeiten., aber da kenne ich mich nicht aus...und da bin ich mit meiner winzigen Anwendung aussen vor.
Es gibt aber genug Literatur dafür.
Für meine Zwecke (Db für eine Ballettschule mit FE Access und Backend Ms Sql db) ist es super. Ich kann für alle Informationen sofort sehen, wie sie sich entwickelt haben.
Ich hatte mir selbst ein Archivkonzept entwickelt, das kann ich jetzt in die Tonne kloppen...
Ukulele befürchtet, das bei seinen großen Datenmengen das ganze ein oversized Problem wird. Das sehe ich bei großen DB's durchaus auch so... es gibt da aber Möglichkeiten., aber da kenne ich mich nicht aus...und da bin ich mit meiner winzigen Anwendung aussen vor.
Es gibt aber genug Literatur dafür.
Für meine Zwecke (Db für eine Ballettschule mit FE Access und Backend Ms Sql db) ist es super. Ich kann für alle Informationen sofort sehen, wie sie sich entwickelt haben.
Ich hatte mir selbst ein Archivkonzept entwickelt, das kann ich jetzt in die Tonne kloppen...
Ich weiß von der Oracle Implementierung, dass die "alten" Daten in eine automatisch im Hintergrund verwaltete Tabelle verschoben werden. Die Haupttabelle ist also nicht größer als benötigt.
Und selbst wenn nicht, mit einer geschickten Partionierung (z.B. über ein Datum) kann man das auch bei einer einzelnen Tabelle in den Griff kriegen.
Und heutig Systeme kommen ja eh erst bei Tabellengrößen jenseits von "hunderten von Millionen" von Datensätzen in's Schwitzen
Werbung:
ukulele
Datenbank-Guru
- Beiträge
- 5.359
Nicht zwangsläufig, es kommt darauf an. Ich würde vermuten es macht dann Sinn, wenn die Entität nur wenig Attribute hat oder der Anteil an Attributen die sich bei einem Update ändern sehr hoch ist. Speicherplatz an sich kostet ja nicht viel aber wenn du an vielen großen Datensätzen häufig kleine Details änderst entsteht halt ziemlich viel redundante Information.
Und dann kommt es noch darauf an, in welcher Form du historische Daten brauchst. Arbeitest du wirklich damit ist das sehr hilfreich, einfach den Zustand des Datensatzes (oder aller Datensätze) zum Zeitpunkt X bestimmen zu können. Wenn du aber nur Veränderungen nachhalten willst, damit aber nie arbeiten musst, tut es auch eine Log.
Mal eine andere Frage, die Spalten ValidFrom und ValidTo werden immer vom DMBS gesetzt, oder kann ich die auch selbst setzen? Es gibt ja häufig zwei konkurrierende Gültigkeitszeiträume. Der eine ist der Zustand in der DB, der andere der Zustand in der Wirklichkeit. Wenn ich z.B. einen Termin abbilde, gibt es einen Zeitraum in dem der Termin gültig ist und einen, in dem der Datensatz zum Termin gültig ist. Mir ist ersteres viel wichtiger in meiner DB und da muss ich Anfangs- und Enddatum häufig berücksichtigen, wenn ich mit den Daten arbeite.
