nicht angemeldet
Moin dedlfix,
Allerdings sollte man es sich gut überlegen, ob man diese Von-hinten-durch-die-Brust-ins-Auge-Methode wählen will oder ob sich nicht doch was einfacheres findet, und sei es, dass man sich nochmal Gedanken um sein Tabellen-Layout macht.
die Stored Procedures schau ich mir bei Gelegenheit auch nochmal an. Scheint eine Sache zu sein, die man häufiger sinnvoll anwenden kann.
Die Bemerkung zu den Gedanken zum Tabellen-Layout find ich lustig, denn die 'Motivation für die künstliche Herbeiführung des Problems' habe ich überhaupt nur bekommen, _weil_ ich mir Gedanken über die Normalisierung gemacht habe, die ich mir vorher noch nie gemacht habe.
Tatsächlich ist es so, daß ich anfangs in der Tabelle 'aktionen' noch eine Spalte 'beschreibung' geführt habe. Diese Spalte war leicht auszulesen, da sie sich auf einer Ebene mit der Spalte 'aktion_id' befand. Allerdings leuchtete aufgrund der Lektüre der Normalisierungsartikel eine rote Lampe bei mir auf! Der Inhalt dieser Spalte war doppelt vorhanden: in der Tabelle 'aktionen' sowie in den Detailtabellen z.B. 'zeitungen'. Doppelt = nicht gut! Das Feld 'beschreibung' gehört aber eher in die Tabelle 'Details einer Aktion' als zur Tabelle 'Übersicht aller Aktionen', schon weil es verschiedene Arten der Beschreibung gibt. Mal ist es ein Name, mal eine Domain, mal ein Dienstleister.
Die Idee, für die verschiedenen Detailaktionen seperate Untertabellen einzurichten, habe ich hier erhalten. Mein Bestreben ist, bei diesem Projekt die höchste Priorität auf ein _gutes_ Datenbankdesign zu legen und mich erst in zweiter Linie um die korrekten Abfragen zu kümmern.
Ok, da ich mir dieses Mal überhaupt zum ersten Mal ernsthaft Gedanken über ein Datenbankdesign mache, werde ich sicherlich noch einige Fehler und Umständlichkeiten einbauen. Falls Du eine Anregung für mich hättest, immer her damit...
Besten Gruß
JOhnnY