Zitat von
shmia:
Dann muss aber eine andere Art von Abfragesprache vorhanden sein.
Die Abfragen (z.B. welche Kunden haben den Artikel XY zwischen Zeitpunkt1 und Zeitpunkt2 bestellt und nicht reklamiert?)
müssen auf dem Server ausgeführt werden, um die übertragene Datenmenge zu minimieren.
Verknüpfungen oder Aufsummierungen von Daten dürfen keinesfalls dem Client angelastet werden; das wäre ein Rückschritt.
Du wirst es kaum glauben: aber es gibt tatsächlich Auftraggeber die lieber den Server entlasten und die Verknüpfung von Daten auf dem jeweiligen Client machen lassen wollen. Ich gebe dir recht, dass der jeweilige Server gewisse Mechanismen zur Datenreduzierung zur Verfügung stellen muss (z.B. Scopes beim ADS).
Bezüglich der zu übertragenden Datenmengen: wie ist das denn mit
ADO.NET wird da nicht erst der gesamte Cursor übertragen, bis irgendwas passiert? Mit meinem Scopes bin ich da schneller und sparsamer mit der Datenmenge: ich sage dem Server schränke bitte in deinem internen Cache die Datenmenge bei dieser Connection auf diesen Teilbereich ein und schicke mir ggf. den x-ten Datensatz, dabei aber bitte nur diesen Datensatz. Brauche ich einen anderen Datensatz aus dieser Menge, dann fordere ich diesen Satz an, nicht die Automatismen des Server/Client-Systems. Hier spielt natürlich der unterschiedliche Ansatz der Datenbanken-Server eine Rolle: ein Datensatz-orientiertes Systems wird immer nur einen Satz liefern, auch wenn es mehrere Sätze in die gewünschten Kriterien passen, ein Datenmengen-orientiertes System immer die Gesamtmenge.
Vorteil von
SQL-Servern an dieser Stelle mögen Stored-Procedures und Triggers sein, um Geschäftslogiken auf dem Server auszulagern und dort zu bündeln. Aber auch hier muss es nicht unbedingt
SQL sein, ein (Pseudo-)-Datenbank-Server, der dies script-gesteuert selber übernimmt und nur die Schnittstelle zu einem echten Datenbank-Sever darstellt, kann die gleiche Leistung bringen. Ob das nun sinnvoll ist, mag dahingestellt bleiben, ich wollte nur damit zum Ausdruck bringen, dass es nicht immer
SQL sein muss.
Zitat von
shmia:
Ohne Frage ist es weit intelligenter, eine OO Datenbank zu verwenden,
statt die Objekte jedesmal wieder neu irgenwie, (meist mehr schlecht als recht)
auf eine relationale
DB abzubilden.
Nur leider ist in dieser Richtung überhaupt kein Standard erkennbar.
Das ist
IMHO volle Absicht der Hersteller, um einen Wechsel der Datenbank möglichst schwer zu machen.
Tja, der fehlende Standard ist hier wohl wirklich das Problem, ein weiteres sehe ich in der mangelnden Bereitschaft der Auftraggeber sich auf neue Konzepte einzulassen. Hier wird gerne getreu dem Motto "Was der Bauer nicht kennt, frisst er nicht" gehandelt. Mein Versuch neue Datenbank-Modelle (z.B. auch das Einführen einer objektorientierten Datenbank) in meinem aktuellen Projekt einzubringen wurde abschlägig beschieden, weil man nicht weiss wie man z.B. bei beschädigten Dateien diese per Hand reparieren zu können (nur ein Beispiel) und
SQL ist sowieso zu langsam.
