@Jasocul
Darf ich meine Aussagen kurz verteidigen ?
Zitat von
Jasocul:
@jensw_2000:
Bei den meisten deiner Aussagen stimme ich dir voll zu. Bei zwei Dingen kann ich dir nicht folgen.
Zitat von
jensw_2000:
Vermeide möglichst die Verwendung von "hart verbundenen"
DB-Komponenten (Querys, Tabellen, SPs ...) in deinen Applikationen. Erstelle die Verbindungskomponenten zur Laufzeit.
Bei allen
DB-Verbindungen, die visualisiert werden, macht das keinen Sinn. Bei allen
DB-Verbindungen, bei denen es um Datenmanipulation geht (insert, update, delete) gebe ich dir aber Recht..
Es macht
imho generell Sinn, die Verbindungskomponenten zur Laufzeit zu erstellen.
Hier mal die aus meiner Sicht wichtigsten Gründe:
Verbinde ich z.B. eine TxxTable mit meiner TxxConnection, und setze die TxxTable zur Entwurfszeit auf Acitve:=true (um z.B. die Spaltenbreiten meines DBGrids anzupassen oder so ..) und trenne diese Verbindung vor dem Compilieren nicht, dann habe ich ein mächtiges Problem wenn ich mit meiner schönen neuen EXE zum Kunden fahre. Die TxxConnection versucht sofort, wenn sie erzeugt wird, eine Verbindung zu meiner "Entwicklungs-
DB" herzustellen anstatt zum
DB-Server des Kunden ... Das bedeutet Abreise und ein neuer Termin ...
Viele "Anfänger" weisen der Verbindungskomponente die Felder aus der zugrundeliegenden Datenmenge fest zu.
Wenn sie dann mal einen Feldnamen / Feldtyp ändern müssen, verzweifeln sie bei der Fehlersuche ...
Es gibt Anwendungem mit sehr vielen datenvisualisierenden Komponenten. Bei meinen ersten
DB-Anwendungen habe ich auch für jede in der
DB-existierende Tabelle/Abfrage eine Komponente in mein TDatamodul gezogen. Das was zum einen unübersichtlich und zum Anderen hatte es folgende Nachteile:
Beispiel:
An der TTable "tabelle1" in meinen TDatamodul hängen TDatasources in 2 oder 3 Formularen. Wenn ich jetzt in einem dieser Formulare z.B. im tabelle1.AfterScroll eine Statuszeile aktualisiere, dann kostst mich das auch Zeit, wenn das besagte Formular garnicht angezeigt wird. Erstelle ich die Formulare zur Laufzeit dann muss man sogar noch Exceptions umgehen bzw. abfangen ...
Zusätzlich verursacht es nur Probleme, wenn ich in den Formularen individuelle Ereignisbehandlungsroutinen für die
DB-sinsitiven Komponenten verwenden muss. Die Ereignisbahandlungen greifen durch die harte
DB Verbindung letztlich auch in den Formularen, die garnicht aktiv sind.
Bei Client/Server
DB-Programmiereung machen datensensitive Komponenten nur in sehr begrentem Umfang Sinn.
Wenn man die Daten ohnehin zur Laufzeit händisch in "Nicht-datensensitive Komponenten" einliest, warum sollte man dann nicht vor den Einlesen einen passenden TDataset-Nachfahren erzeugen und nach den Einlesen wieder freigeben ?
Das dauert nur wenige Minuten länger, hat aber viele Vorteile. Man muss sich nicht um das DisableConrols/EnalbeControls kümmern, hat keine Zeitverluste durch "unötig" angebundene datensensitive Komponenten und hat zudem noch mit deutlich weniger Fehlerquellen.
Zitat von
Jasocul:
Zitat von
jensw_2000:
Vermeide die Verwendung von Views in der deinen
SQL-Scripten.
Verjoine lieber in jedem einzelnen
SQL-Script die benötigten Tabellen nach Bedarf.
Views sind langsam, nicht immer sofort aktuell, sie fördern einen schlechten Programmierstil und sind zudem noch unflexibel.
Sorry, aber das ist Blödsinn
Das ist definitiv kein Blödsinn.
Imho unterstützt nur der
MSSQL/
MSDE eine Möglichkeit Views zu indizieren. Dazu müssen diese View jedoch Schema-gebunden sein (bis
MSSQL-2000) was bei 99,5% aller Views nicht der Fall ist.
Indizierte Views sind je nach Komplexität und Abfragehäufigkeit bis zu 1000% schneller. (
Technet Artikel).
Verjoint man jetzt noch Views miteinander, hat man die Performancevorteile eines RDBMS komplett vernichtet. Der
SQL-Server wird schneller an seine Leistungsgrenzen getrieben und wird sich beim Anwender mit DeadLocks u.Ä. dafür bedanken.
Views sind wirklich nicht immer sofort aktuell. Ich wollte das auch nicht glauben.
Ich hatte bei der Final-Release meiner Callcenter Software eine relativ komplexe SP verbaut, die den Agenten einen freien Kontakt zum Anrufen liefert. In der SP habe ich u.A. geprüft ob der Agent berechtigt ist diesen Kontakt anzurufen, ob der Kunde schon einmal angerufen wurde und was dabei herausgekommen ist, ob der Kontakt bei jenamden in der Wiedervorlage steht usw ...
Am Ende wurde die ID des Kontaktes dann in eine Sperrtabelle eingetragen und dann der entsprechende Datensatz aus der Kunden-Tabelle abgerufen und an den Agenten zugestellt.
Alles über Views, weil das so schön einfach war ...
Sobald viele Agenten im Callcenter waren (also entsprechend hohe Serverauslastung) kam es ein paar mal am Tag spontan vor, das ein und der selbe Kunde in kurzen Zeitabständen mehrfach hintereinander angerufen wurde. Bei der Fehlersuche in der
DB war nie etwas zu finden. Alle Staties (bereits angerufen, kein Interesse, Wiedervorlage usw.) waren sauber gesetzt.
Ich habe mir über Wochen den Wolf gesucht und keinen Fehler gefunden.
Letztlich hat mich
Leuselator dazu überredet die SP umzustellen und alle Views daraus zu verbannen.
Ich habe die Joins 1:1 aus den Views übernommen und diese direkt aus der SP aufgerufen.
Seither ist der Fehler verschwunden und die SP wird mehr als 10 mal so schnell abgearbeitet ...
Die CPU Auslastung auf dem
SQL-Server ist (bei vollem Callcenter) von rund 40% auf etwa 15% gesunken.
Daher mein Ratschlag an alle, die
SQL Datenbanken entwickeln:
Views sind langsam und nicht immer sofort aktuell.
Verwendet Views nie in SP's, Funktionen und veschachtelten Abfragen, sondern verjoint die zugrundeliegenden Tabellen direkt.
Schöne Grüße,
Jens
