Well, well, well - also mein Senf zu dem Thema...
| Zitat von Froggie: |
| (bei >1.000 Personen und >500.000 Buchungen). |
Du schickst/ziehst 501,000 Datensätze zum Client um die dann in Listen zu
verheiraten? Wie jaensen schon gesagt hat, lass sowas die Datenbank (den App-Server) vorfiltern. Heute sind Fat-Clients zwar Standard aber du belastest damit ungemein den I/O Traffic der Datenbank und das Netzwerk.
| Zitat: |
| Kann man soetwas nicht besser und schneller mit DataSets lösen? |
Klar. Das Filtern ist hier um ein vielfaches schneller, weil die DataTable (im DS) darauf optimiert ist.
| Zitat: |
| Wie sieht es eigentlich mit dem Speicherverbrauch eines DataSets im Vergleich zu Listen aus? Ich habe gelesen/gehört, dass DataSets ziemlich viel Speicher benötigen, aber dafür sehr performant seien. |
Zweimal korrekt. Der Speicherverbrauch von DataTables deutlich höher als der einer Liste. Eine liste ist intern einfach ein statisches Array mit deinen Items. Eine DataTable ist ein Red-Black-Tree. Dieser ist zwar extrem performant für Suchen kostet aber natürlich seinen Preis. Hier könntest du bei 500,000 Items einen Unterschied im Client merken.
| Zitat: |
| Ein DataSet besteht aus mehreren DataTables und die DataTables wiederum aus mehreren DataRows und eine DataRow entspricht dabei genau einem meiner Businessobjekte. Dann kann man wiederum die Tabellen in Beziehung setzen (ganz wie bei einer Datenbank also). Außerdem habe ich gelesen, dass man DataSets vergleichsweise einfach und performant filtern und sortieren kann. |
Okay, jetzt wird's endgültig eine Grundsatzdiskussion
Eine Datenbank ist eine Datenbank, ein Business-Layer ist ein Business-Layer und ein Client ist ein Client. Die Tabellen einer Datenbank sind nicht zwingend 1:1 mit Business-Objekten (Geschäftsobjekten
) zu vergleichen. Ein paar einfache Beispiele:
1.)
(Beispiel aus einem recht aktuellen Thread hier auf der Seite)
Sagen wir wir bauen eine Medien-Bibliothek welche CDs, Bücher und DVDs verwaltet.
Hierbei macht es datenbankseitig Sinn eine Haupttabelle "Media" zu benutzen welche für alle Medien geltende Informationen (Title, SubTittle, PublicationDate, ...) zu verwenden. Es macht jedoch keinen Sinn alle möglichen Felder aller Medien-Typen in diese Tabelle zu stecken. Das zerstört alle Skalierungsmöglichkeiten. Dafür hat man dann spezielle Tabellen "MediaBook", "MediaCD", ... . Diese Tabellen beinhalten Attribute welche spezifisch für dieses Medium gelten.
Client-seitig macht es jedoch keinen Sinn eine Klasse Media zu haben welche dann über Properties "MediaBook" oder "MediaCD" mal hat und mal nicht. Man verwendet eine Klasse "Media" als Basis und erbt von dieser alle anderen Media-Typen ab. Dabei ist es recht egal woher diese Daten in der Datenbank kommen.
Dafür baut man dann beispielsweise Prozeduren die Sets von Haupt-Informationen (gefiltert) zurückgeben (usp_GetMediaByMyCriteria). Diese geben den allgemein gültigen Rumpf der Objekte plus den Medien-Typ zurück. Damit kann der Business-Layer auch direkt die richtigen Objekte erzeugen.
2.)
Sehr beliebt:
Tabelle "PersonAddress". Die hat dann gerne Spalten Name1 bis Name10, Email1 bis Email15, ... . Die wenigsten Personen haben mehr als zwei Namen oder mehr als 3 Email-Adressen. Aber man muss natürlich auch in der Lage sein Scheich irgendwen mit 15 Namen (wenn’s reicht) speichern zu können. Außerdem will sich auch der Internet-Junkie mit Email-Adressen bei so ziemlich jedem öffentlichen Provider dieser Welt nicht beschnitten fühlen.
Datenbankseitig baut man eine Tabelle mit den absoluten Standard-Feldern, mehr nicht. Dazu entweder (wenn man beim Speichern sehr flexibel sein will) eine XML Spalte welche dann als Property-Bag fungiert oder ein EAV Modell. Letzteres ist zwar deutlich umständlicher zu pflegen, aber wesentlich performanter wenn man nach Name12 oder TelefonNummer8 wirklich suchen will.
Gerade ein EAV Design ist Client-seitig aber in Betrachtung des daraus resultierenden Klassenmodells ein Unding.
Hierfür kann man jetzt Prozeduren bauen welche einmal die allgemein gültigen Adressinformationen zurückliefen und zusätzliche welche dann wirklich alles oder spezielles zurückgeben. Diese Informationen benötigt man in den meisten Applikationen an ca. 2 von 100 Stellen.
(Mein) Fazit zu Datenbanken:
Eine Datenbank ist mit einem (Web-)Service zu vergleichen. Bedeutet, sie liefert Daten in einer Form zurück welche (ungefähr) meiner Business-Logik entsprechen. Wo diese Daten jedoch im Backend gespeichert sind/waren/werden ist im Client egal.
| Zitat: |
| DataRow entspricht dabei genau einem meiner Businessobjekte |
Man kann Business-Objekte schon über DataTables/DataRows abbilden. Das hat aber nicht immer nur Vorteile. Ich persönlich ziehe hier eigene Objekte vor. Dabei bin ich flexibler und der Mehraufwand am Anfang rechnet sich eigentlich recht bald. Das Argument mit der "Suchmöglichkeit" ist auf jeden Fall zutreffend. Die DataTable bietet ein sehr schönes Interface um auch recht komplexe User-Suchen zu realisieren. Dafür kann man, wenn man faul ist wie ich
, ein/zwei Methoden basteln welche die eigenen Objekte mal schnell in eine DataTable stecken.
Mit zu 100% über DataSets/DataTables realisierten Business-Objekten kann man halt Probleme mit sehr komplexen Strukturen bekommen; oder schlich an Grenzen stoßen
So, das war das Wort zum Sonntag
Flo
