Entwicklung eines Datenbanksystems

Ich bedanke mich für beide Sichtweisen!

ich wollte trotzdem gerne einmal wissen, warum man das Transaktionslog nicht irgendwie für Versionierung nutzen kann (?).

https://en.wikipedia.org/wiki/Transaction_log:
[...] a log is a file listing changes to the database, stored in a stable storage Format. [...]
[...] In computer storage, a journal is a chronological record of data processing operations that may be used to construct or reinstate an historical or alternative version of a computer system or computer file. [...]

Wieso greift man darauf nicht zu?

Oder ist das wirklich nur Änderungsinformation, die man manuell nachbauen muss, falls irgendwas zerschossen wird?
 
Werbung:
Das ist schlicht ein interner Mechanismus, der nur dazu dient, die Integrität der Daten auch über einen Systemcrash hinweg beibehalten zu können. Wenn eine Transaktion ausgeführt wird, beispielsweise eine Zeile eingefügt wurde, aber der zweite Teil der Transaktion, ein weiterer Datensatz noch nicht geschrieben ist und dann das System abstürzt, hast Du nach dem Neustart eine inkonsistente Datenbank. Um das zu verhindern, gibt es das transaction log. Das für ein logging zu nutzen, ist eine abwegige Idee.
 
Hallo nochmal.
Ich habe eine kurze Frage zu den oft erwähnten SICHTEN/VIEWS.
wie sinnvoll ist es für mich darauf einzugehen? Für mich ergeben diese VIEWS foglenden sinn:
1.) Vereinfachung von Abfragen durch vorher definierte VIEWS
2.) Datenschutz, weil jedem Benutzer ein eigener Teil der DB zugeordnert wird
3.) Zusammenführung von Datenbanken: Einen VIEW mit allen zur Anbindung nötigen Attributen erzeugen, der einfach benutzt werden kann ohne das sich der andere Datenbankn-Administrator in mein System reindenken muss.

Einer meiner Schwerpunkte ist im Moment das Storyboarding: Aufbau der Eingabemaske mit allen nötigen Regeln und Rollen und das ERM/ Rel Diagramm hintendran.
Ich dachte mir nämlich, dass ich durch den LOGIN in meiner Maske die Rolle des Benutzers schon erkennen kann und dementsprechen die Felder,Buttons blockiert/freigeschaltet sind. Wozu brauche ich dann genau VIEWS außer natürlich, um meine Abfragen zu vereinfachen?
Betreffend Punkt 3 reicht es meinem Chef, dass ich nur sage "das kommt von da". Groß auf tabellen-kombinierung etc muss also nicht eingehen.

Hab ich vielleicht irgendwas wichtiges außer Acht gelassen?

Grüße
 
1. Komprimierung der Select-Abfragen:
Du wirst schnell merken das es einige Statements gibt die du an diversen Stellen einbauen musst. Das ganze in einer View abzulegen hilft dir (also dem Entwickler)...
Die View muss dann nichtmal für die User freigegeben sein... :)

2. Sicherheit:
Vllt. willst du diversen Leuten nur berechnete oder aggregierte Werte aus einer Tabelle, nicht aber den Tabelleninhalt selbst freigeben...
Einfach ne View drüber hauen und eben nur diese Berechtigen... :) Auf die Tabelle kann sie/er dann nicht zugreifen...

3. Übersichtlichkeit:
In deinem Front-End sieht es definitv schicker aus wenn du einfach nur von einer View selektierst, als wenn du jedesmal 30+ Zeilen Code gegen die Datenbank wirfst...

Zumindest das, was mir so on-the-fly einfällt :)
 
Erinnere Dich daran, warum es so viel um Views ging: Du kamst am Anfang mit der Zusammenführung von zig Datenbanken. Wenn Du das mit Views innerhalb der Datenbank realisierst, kannst Du danach beliebig darauf zugreifen und musst Dich nicht mehr für die Anbindung und den Zugriff auf die entfernte Datenbank interessieren. Und vielleicht möchte jemand anderes auch in einer anderen Anwendungen alle diese entfernten DBs verknüpfen. Hast Du Views angelegt, ist das eine Sache von Minuten, das zu übernehmen. Deshalb sind Views gerade dafür das non plus ultra.
Das Gegenbeispiel wäre alle komplexen Abfragen in den eigenen Programmcode zu stecken. Wenn dann später der Informatik-Kollege dazu eine Anwendung schreibt, müsstest Du ihm antworten: Ja, hab die Anfragen, die sind hier in meinem Quellcode, such Dir die passenden raus. Mit Views könntest Du ihm antworten: Ja, guck mal dort die Views in der DB, die sind alle kommentiert und haben einen aussagekräftigen Namen. Meld Dich, wenn Du noch Fragen hast.
Das heißt, immer dann, wenn es komplexe Abfragen sind oder wenn sie eventuell noch einmal genutzt werden könnten, mache Views draus. Und versuche so wenig wie möglich in Dein Programm zu ziehen.
 
Danke, nun ist es mir klar. war also garnicht so weit entfernt.

ich habe eine weitere ganz andere Frage:
Wie setzt man am besten sich gegenseitig ausgrenzende Dropdown-Menüs um? Beispielsweise die Aufbauregeln von einem Produkt.
Also einer Entität A sind nur bestimmte Tabellen der Entität B zugeordnet und auch der Entität B sind bestimmte Tabellen der Entität C zugeordnet. Entität D bezieht sich dann auf die Kombination von A, B und C und hat dann nur noch wenige Tabellen übrig.
Wie setzt man das um, weil man ja warten muss bis A, B und C getätigt sind? Eignetlich müsste man dann alle Dropdown-Menü nacheinander ausführen. Mir wäre es aber am liebsten, wenn man Anfangen kann wo man will. Gibt es da irgendeine spezielle Variante oder ein Tool?

Grüße
 
Reine Front-End Problematik... Die Datenbank hält nur die Daten... Wann du welche Daten haben willst ist der Datenbank ja erstmal egal :)

Einfach ein paar If-Abfragen in das Event "Change Value" oder wie es auch immer heißen mag (das Event das triggert wenn sich der Wert der Combobox ändert...)
 
Jetzt willst Du auch noch mal eben javascript und jquery lernen? Ein Tool wie der Maestro PHP Generator bringt so ein Multilevel Autocomplete Feature mit. Ansonsten halt selber mit jquery realisieren. Für die Fragen musst Du Dir aber ein javascript-Forum suchen.
 
@Tom. S: nein das muss ich nicht umsetzen, sondern nur "konzeptionieren". Also ein "Baukasten-Prinzip" für ein paar Produkte erstellen und sagen wie man das darstellen und umsetzen könnte.

Ich habe nochmal ein paar Fragen zur Versionierung:
Das beispiel von Distrilec mit dem umlackierten Auto und old/new flag bezieht sich ja nur auf eine Tabelle. Aber ich glaube es soll eine Version der kompletten Tabellen-Struktur gemacht werden. Weil die ganze Tabellenstruktur aus Teilen der Aufwandsabschätzung besteht: Schätzungsmodelle, Projekte, die Produkte, Kunde etc. Wenn ich eine Version bei Änderungen für nur einzele Tabellen erzeuge, kann ich nur Versionen für einzelne Entitäten finden. Ich weiß nicht so genau was mir das bringen soll, weil alle anderen Tabellen eine ganz unterschiedliche Anzahl an Versionen haben. Wie greife ich daruf logisch zu? Z.B. wenn ich mir die Schätzungszusammenfassung von dem Zeitpunkt ansehen will, an dem der Kunde den Vertrag unterschrieben hat mit ALLEN Tabelleninfos.

Besser wäre es, wenn bei einer Änderung egal wo ein komplette Versions-Snapshot der ganzen Datenbank gemacht wird, weil nur dann kann man Schätzung Version 1, Schätzung Version 2, 3 ,4 etc finden oder liege ich falsch?

Diese Versionierung ist dahingehend sehr wichtig, weil Kunden oft ihre Meinung wechseln, dann muss man den Snapshot der kompletten Schätzung von beispielsweise vor 1 Jahren finden.

Es muss auch Datenbank-Snapshots zu festen Zeiten des Geschäftszyklus geben. Beispielsweise Snapshot der Schätzung zum Zeitpunkt des Produktionsbeginns, zum Zeitpunkt des Signierungsprozesses und zum Zeitpunkt anderer Phasen der Produktentwiclung.

Könnt ihr mir sagen wie viel Speicher das ca frisst, wenn bei Änderungen, sagen wir mal 100 Änderungen bei 10 Tabellen mit 10 Attributen, 100 Kopien erzeugt werden.
Das die Erzeuger einer Schätzung ein bisschen Rumspielen können, dachte ich mir das es eine Sandbox-Version gibt, die man aktivieren oder deaktivieren oder übernehmen kann. Das wäre also in allen Tabellen eine weitere boolsche Variable "Sandbox? - Yes/no" mit der man das umsetzen kann, oder?

Dann noch zum Thema Historien-Bildung. Reicht dafür das Transaktionslog aus? Ich hatte noch kein Einblick in ein solches Log. Kann man aus diesem Log alle Änderungen, Datum und Name des Änderers heruaslesen?

Grüße
 
Zuletzt bearbeitet:
Du verkomplizierst dir das ganze...
Was hindert dich daran den Timestamp der einzelnen Revisionen zu prüfen ? (Ein Anlagedatum sollte ja sowieso immer vorhanden sein...)

Edit:
Hier nocheinmal der Hinweis... Vergiss das Transactionlog... Das bringt dir hier garnichts...
 
Ich formuliere die Frage mal anders:

Wie führe ich in ein Datenbankschema eine Versionierung von festen Punkten im Geschätsprozess ein.

Also der Status aller Tabellen zu dem Zeitpunkt als jemand den Knopf "In Production" oder "Business Awarded" gedrückt hat. Un müssen wirklich alle informationen sein: Kostenstellen, Projekte, Produkte, Kosten&Resourcen zuordnungen, Kunde, Start of Production, Development time, etc.... Das sind alles dinge die sich ständig ändern können.

Wäre das dann nicht doch eine Archivtabelle, die beim setzen des Flags von allen Entitäten die IDs übernimmt?
 
@Distrilec: Meinst du vlt. das man einen ganzen Datenbanken-Rollback durchführen kann zu einem bestimmten Zeitpunkt, wenn man alle Änderungen mit Datum gespeichert hat? Das einzige was ich im Internet zu dem Thema finde sind komplizierte Masterarbeiten oder Studienarbeiten :D
 
Säsch schrieb:
@Distrilec: Meinst du vlt. das man einen ganzen Datenbanken-Rollback durchführen kann zu einem bestimmten Zeitpunkt, wenn man alle Änderungen mit Datum gespeichert hat? Das einzige was ich im Internet zu dem Thema finde sind komplizierte Masterarbeiten oder Studienarbeiten :D
Zum Vergrößern anklicken....
Nein... Ohne irgendwelche Funktionen zu vergewaltigen, damit man das gewünschte Ergebnis bekommt... Ist das schlichtweg nicht möglich... (Die Links von @akretschmer beschreiben auch nicht genau das, was du haben willst...).

Da hilft kein Transactionlog, kein Flashback, kein Rollback... Es gibt im Standard Datenbankverhalten (und das behaupte ich jetzt einfach mal für jede Relationale Datenbank) keine Möglichkeit eine Art Snapshot wegzusichern... Und dieses dann anstatt der eigentlichen Daten zu verwenden...

Ich verstehe aber immer noch nicht warum ein Datumsfeld und die Bedingung (table.entry_date <= &MeinGewuenschtesDatum) nicht ausreichen...
 
Werbung:
Naja. Man kann ein Basebackup machen und dann alle Transaktionslogs aufheben. Damit kann man dann recht einfach PITR machen : Point In Time Recovery.

Aber ich gehe davon aus, daß auch das nicht das ist, was der Fragesteller sucht.

Die von mir genannten Links geben aber die Möglichkeit der Abfrage, wie eine Tabelle zu einem Zeitpunkt X mal aussah.
 

Ähnliche Themen

J
Agile Build & Release Manager (m/w) – am Standort München
Antworten
0
Aufrufe
4K
Job Ambition GmbH
J
A
Trainee zum (Junior-) Softwarearchitekt bei innovativer Softwareberatung
Antworten
0
Aufrufe
3K
AcademicWork
A
Zurück
Oben