Vergleich TTable-TQuery aus Entwickler 6.99

[Holger Klemt]

Nur mal so als Anmerkung:

Ich hoffe, das der Vergleich TTable-TQuery von Andreas in der aktuellen Ausgabe des Entwicklers nicht wirklich ernst genommen wird:

Als Argument für die TTable einen Filter zu nehmen halte ich für (ich sage es ganz offen) <b>Schwachsinn!</b>

Wenn man SQL Server programmiert, programmiert man in SQL!
Wenn man das nicht kann, muß man es lernen!

Dieser Artikel kann unerfahrene Programmierer in eine ganz falsche Richtung treiben.

Die Stärken von SQL liegen in der Verbindung der Daten aus mehreren Tabellen, wozu eine TTable eh nicht in der Lage ist (ich will die gnadenlose Performancebremsen mit der Bezeichnung *Lookup* gar nicht erwähnen)

Wenn man also Informationen aus nur einer Tabelle filtern möchte, dann soll man sie so filtern, wie es der Server am besten kann, also bei Paradox mit dem Filter und bei SQL Servern wie Interbase mit SQL (deshalb nennt man die auch so)

Dieses ist kein Vorwurf gegen Andreas, der sich wahrscheinlich nur der tragweite dieses Artikels nicht bewußt war (ein Kunde hatte mich angesprochen, daß die TTable doch viel besser sei) und von dem ich aus seinen Büchern und Artikeln weiß, daß er den Sinn von Client Server Anwendungen und SQL sehr wohl verstanden hat!

Gruß an alle

Holger

[Andreas Kosch]

Hallo Holger,

Deine Feststellung <i>Dieser Artikel kann unerfahrene Programmierer in eine ganz falsche Richtung treiben</i> ist für mich nicht nachvollziehbar. In diesem Beitrag ging es darum, auf die Notwendigkeit des <b>SQL-Monitors</b> hinzuweisen, damit solche Fehler <b>nicht</b> gemacht werden. Also habe ich ein Beispiel gewählt, das die Auswirkungen drastisch verdeutlicht - die Folgen sind in den Abbildungen des Beitrags zu sehen (Anzahl der FETCH-Aufrufe etc.). Und wenn man sich in diesem FORUM etwas umschaut, wird man häufig auf derartige Fragen stoßen.

In dem Beitrag steht nicht, das TTable generell besser als TQuery ist. Allerdings ist die pauschale Vorverurteilung von TTable (entstanden zu Zeiten von Delphi 1 und 2) nicht mehr gerechtfertigt, im Einzelfall ist auch TTable nützlich (was anhand des automatisch generierten SELECTs nachgewiesen wurde). Und um zu prüfen, ob die eigene Bequemlichkeit nicht vom Server <i>bestraft</i> wird, reicht ein kurzer Blich auf die Logs vom <b>SQL-Monitor</b> (womit sich der Kreis meiner Argumentation schliest).
&#10

[Holger Klemt]

SQL Monitor halte ich ebenso für wichtig, trotzdem:

Das Resume des Kunden war: Benutzt besser die TTable als die TQuery!
Ob der das alles verstanden hat laß ich mal im Raume stehen!

Die Anzahl der Fetches kann man mit SQL in einer TQuery vorher abschätzen, wer also darauf noch einen Filter setzt, naja,
ich vermisse einfach einen grundsätzlichen kritischen Hinweis aus die Filter Eigenschaft! Diese sollte man bei SQL Servern aus seiner Programmierung streichen!

Man ruft ja auch nicht bei der Telefonauskunft an und läßt sich das Telefonbuch vorlesen, um dann den richtigen Eintrag abzuwarten.

Gruß
Holge

[Andreas Kosch]

Hallo Holger,

in dem Beitrag ging es nur um die Techniken, wie man automatisch generierte SQL-Anweisungen nachprüfen kann: <br>
a) <b>SQL-Monitor</b> aus Delphi 4 C/S oder Delphi 5 Enterprise<br>
b) <b>BDE-Callback</b> für die Professional-User, oder <br>
c) <b>TIBSQLMonitor</b> für IBX-Anwender <br>
Dazu wird natürlich ein plausibles Beispiel benötigt, und nur daher das Filter. Die Gegenüberstellung von TTable zu TQuery nimmt in diesem Beitrag nur 3 Absätze in Anspruch wobei am Ende der folgende Satz steht: <i>"Damit will ich nicht sagen, das TTable besser als TQuery ist. Eine pauschale Aussage ist nicht angebracht, statt dessen müssen Sie immer den konkreten Einsatzfall betrachten. Allerdings brauchen Sie ein Tool, das die ausgelösten SQL-Anweisungen anzeigt"</i>.

Man braucht schon eine starke Phantasie, um aus diesen Sätzen den Vorwurf abzuleiten, ich würde unerfahrene Entwickler auf die falsche Färte lenken.

Und im übrigen ist der Satz <i>"...ich vermisse einfach einen grundsätzlichen kritischen Hinweis aus die Filter Eigenschaft! Diese sollte man bei SQL Servern aus seiner Programmierung streichen."</i> falsch - denn TTable kann einen geeigneten Filterwert in eine ideale SQL-Anweisunge (WHERE-Einschränkung) umsetzen. Derart pauschale Aussage führen unerfahrene Entwickler auf die falsche Fährte, denn mit dem pauschalen Verzicht macht man sich unnötige Arbeit

[Holger Klemt]

bevor das ausartet:

Sollte eine TTable mit Filter ein besseres SQL liefern ;-) als es einem SQL Programmierer für die TQuery einfällt, so nehm ich alles zurück!

Wer als Überschrift "Client Server Secrets - SQL Anweisungen für den Server" wählt muß sich den Vorwurf gefallen lassen, daß dieser Artikel beim Leser eine Tendenz bildet! Diese Tendenz ist (mit Vorbehalt in dem Satz: Damit will ich nicht sagen, daß TTable besser als TQuery ist, ...):die TTable mit Filter ist besser.

Mein Tip an alle Programmierer: Wenn Ihr was von einem SQL Server wie InterBase wollt, dann "sagt" es Ihm in SQL! Nur dieser Weg ist dauerhaft erfolgreich.

Im übrigen:

Den SQL Monitor bzw dessen Informationen (z.B. auch über BDE Callback) halte ich für extrem wichtig, weil man damit vielen Programmierern zeigen kann, warum eine Anwendung schnell oder langsam ist.

Aus diesem Grunde ist dein Artikel auf jeden Fall Pflicht für jeden, der über die Performance mit Interbase oder die BDE meckert, denn was man zunächst als unnötige Mehrarbeit empfindet, macht sich im Rahmen eines Projektes, sei es auch noch so klein, sehr stark bemerkbar, wenn man mit realen Datenmengen arbeitet

Gruß

Holge

[niceday]

Hallo Holger !

Grundsätzlich pflichte ich Dir bei, daß Fachartikel kritisch
hinterfragt werden sollen; auch wenn sie von nachweislich fähigen Leuten wie Andreas Kosch stammen. Allerdings glaube ich, daß Du Andreas hier unrecht tust. Wenn Dein Kunde nicht die nötige Kompetenz besitzt, um fachlich korrekte Aussagen auch korrekt zu beurteilen, so sind nicht die Aussagen das Problem, sondern der Kunde. Meiner Meinung nach ist es dann Deine Aufgabe dem Kunden den Kontext, in dem die Aussagen vom Andreas zu beurteilen sind, nahe zu bringen.

bye, ad

[tp]

Hallo Holger,

was Andreas dort in seinem Artikel aufgeschrieben hat, war so eigentlich gar nix neues. Daß eine Table über die internen Strukturen der Datenbank bescheid weis, solltest Du eigentlich am besten wissen. Woher kommen denn sonst die ewig langen Abfragen über die Systemtabellen beim Öffnen einer TDataBase...

Ganz davon abgesehen finde ich die Art der Diskussionsführung sehr herabwürdigend. Ich glaube nicht, daß sich zwei Menschen mit einem derartigen Schatz an Erfahrung in dieser Art und Weise über ein solch nichtiges Thema unterhalten sollten.

Wenn Dein Kunde den Unterschied zwischen TTable und TQuery noch nicht kennt und auch nicht weis, was im Untergrund von Delphi für Statements gebildet werden, sollte er mal in eine Schulung von euch gehen.

cu,

Thoma

[Holger Klemt]

die hat er mittlerweile auch bekommen ;-) und die hat ihm gut getan!

Bezüglich meines Tones:

Entschuldigung an Andreas, war ein wenig heftig, geb ich zu.

Gruß an alle
Holger
(P.S.:wir sammeln gerade die Themen für das neue Interbase 6 Buch, bitte [email protected]