Hallo,
Zitat von
HaJo:
Nun muß ich Thomas F mal fragen, was das denn soll
In der Regel hat man beim Programmieren von Datenbankanwendungen ein Gerüst der Datenbank schon erstellt, um das herum man seine Anwendung baut.
Sollte es dann doch einmal nötig werden, aus dem Programmablauf eine neue Tabelle zu erstellen, wird diese in der Regel auch mit Daten gefüllt und mit einem Post oder Commit abgeschlossen.
Diese Daten sind dann auch vorhanden!
Ein solches vorgehen sehe ich lediglich bei Exportfunktionen für andere Anwendungen.
Denn:
Aus dem laufenden Programm erzeugten Tabellen, läßt sich aus dem laufenden Programm nun mal kein kein zusätzlicher Quelltext zuordnen, der das arbeiten mit solchen Tabellen intelligent im Programm verewigt.
Was soll das ganze also?
das sehe ich anders.
Für meinen Administrationsjob muss ich aus diversen Systemen Daten sammeln und auswerten. Für die Protokolle des Mailservers gibt es je Tag eine Tabelle, die zur Laufzeit erstellt wird. Der Zugriff erfolgt über Namenskonventionen. Eine einzige Tabelle wäre mir hier zu schnell zu groß. Beim Befüllen der "Tages-Tabellen" werden andere Tabellen mit "Statistikinformationen" gefüllt. Die "Tages-Tabellen" werden sporadisch (nach Zeitablauf) gelöscht. Natürlich könnte man dazu eine Tabelle nehmen und dort zeitabhängig Teilmengen löschen, die Laufzeit der Befüllung und das Löschen der nicht (mehr) benötigten Daten (Drop Table) ist bei der von mir gewählten Verfahrensweise aber deutlich kürzer, als bei einer großen Tabelle.
Ähnlich verfahre ich bei der Auswertung der Ereignislogs der Server. Jeder Server hat "seine" Tabellen. Zugriff erfolgt über eine View. Wenn ein Server wegfällt, lösche ich dessen Tabellen und passe die View an. Tabellen für neue Server werden automatisch erstellt, hier muss ich nur die View anpassen (kommt sehr selten vor). Bisher ist diese Vorgehensweise extrem wartungsarm. (Und wenn ich mal Langeweile habe, bau ich mir noch 'ne Routine, die die View automatisch anpasst.
)