Welcher Datentyp?

[barnti]

Hallo,
ich speichere die Datensätze meiner Tabellen in Objekten. Welche Struktur wäre angebracht, um alle Datensätze einer Tabelle darzustellen? Was bietet sich da an? Array of 'MeinObject', Objectlist, Verkettete Liste...

[mirage228]

Naja,

ich verwende gerne TObjectList - vielleicht ist das ja auch was für dich. Probiers einfach mal aus. ;)

Generell lässt sich sagen, dass du das benutzen sollst, womit du am besten klar kommst. :)

mfG
mirage228

[MacGuyver]

Moin auch!

Bei kleinen Datenmengen nehme ich immer TStringList in Kombination mit Pipe-Strings.

In der Zeile steht dann

Code:

Wert1|Wert2|WertN

Voll gut, die Dinger. Mit SaveToFile und LoadFromFile kannst du den Kram direkt speichern. Bei der Anzeige verwende ich gerne eine Listbox die ich selber Zeichne. In dem Format ist man an Spaltenbreiten nicht gebunden.

Stefan

[barnti]

Zitat:

Zitat von mirage228

Generell lässt sich sagen, dass du das benutzen sollst, womit du am besten klar kommst. :)

Tja, aber wie ist es bei großen Datenmengen? Wenn so eine Tabelle mal eben 50.000 DAtensätze enthält. Ist es dann immer noch egal? Dann wären Pointer sicherlich die richtige Wahl. Aber die Verwaltung ist gruselig und immer ein Bisschen fehleranfällig.

[MacGuyver]

Hai,

lege doch einen Packed Record nach deinen Vorstellungen an und hole entsprechend Heap-Speicher. Ein Pointer und ein Speicherbereich. Mußt du dann nur merken, wieviele davon belegt sind.

Stefan

[barnti]

Hi,
dann könnte ich doch auch gleich alle Objekte meiner Tabelle als Liste anordnen. Über ein Feld 'Next' könnte ich dann auf alle Daten zugreifen. Vielleicht ist das der beste Ansatz für OOP...?

[MacGuyver]

Hä? :gruebel:

Objektorientiert ist nicht immer die erste Wahl. In vielen Situationen kapseln Leute Scheiße, die gleich weggespült werden könnte. Spaß bei Seite. Muß das überhaupt OOP sein? Wenn man geschickt mit Parameterübergabe arbeitet braucht man nicht immer ein Objekt.

Stefan

[barnti]

Zitat:

Zitat von MacGuyver

Objektorientiert ist nicht immer die erste Wahl.
...
Muß das überhaupt OOP sein? Wenn man geschickt mit Parameterübergabe arbeitet braucht man nicht immer ein Objekt.
Stefan

Da ich das ganze in einer Drei-Schichten-Architektur lösen möchte, ist die Antwort ja, es muss OOP sein. Es ist ein größeres Projekt - auf Dauer wird es deutlich einfacher die Sache zu warten. Außerdem fällt das Überarbeiten leichter, wenn etwas geändert wird oder neue Funktionalität hinzukommt.
Weiterhin arbeite ich Entwurfsmustern, die auf dem Konzept der OOP basieren.

Es sollte also ein 'OOP-freundlicher' Ansatz sein.

[maximov]

Zitat:

Zitat von MacGuyver

Hä? :gruebel:

Objektorientiert ist nicht immer die erste Wahl. In vielen Situationen kapseln Leute Scheiße, die gleich weggespült werden könnte. Spaß bei Seite. Muß das überhaupt OOP sein? Wenn man geschickt mit Parameterübergabe arbeitet braucht man nicht immer ein Objekt.

Stefan

Ja, die leute kapseln Scheisse und machen mit OOP Gold daraus :mrgreen: Aus Scheisse Gold machen is auch eins meiner hobbies. Im ernst in den meisten fällen macht OOP (COP) sehr viel sinn, erst recht wenns um komplexe strukturen geht. Und alle daten in parametern zu halten dürfte schwer werden :gruebel:

[barnti]

Hallo,
eben darum lieber OOP. Mein Vorschlag wäre:

[maximov]

Warum nicht? Würde aber eine doppelt verkette liste machen, dann könnten sich die object selbstständig aus der lsite lösen - ohne fremde hilfe.

[choose]

Hallo barnti,

kannst Du Dein Problem einmal etwas genauer darstellen? Aus Deiner Aussagen:

Zitat:

Zitat von barnti

ich speichere die Datensätze meiner Tabellen [..]. Welche Struktur wäre angebracht, um alle Datensätze einer Tabelle darzustellen?

und

Zitat:

Zitat von barnti

[..]in einer Drei-Schichten-Architektur

schließe ich, dass Du eine serverseitig abgelegte Datenmenge, auf die Du mithilfe eines Erben von TDataSet (zB TTable) zugreifen kannst, auf dem Klient für die Dauer des Prozesses oder auch darüber hinaus möglichst komfortabel verarbeiten möchtest. Hierzu ist nicht nur eine reine Speicherhaltungs- und Kopiertechnologie notwendig sondern auch Ansätze zur vereinfachten Pflege. Sollte sich zB die Struktur Deiner Daten nachträglich ändern, sollte ein Abgleich Deiner klienrseitigen Datenmenge weiterhin möglich sein.

Wenn ich das richtig überblicke, sollte der Einsatz eines Exemplars von TClientDataSet, dem von Borland propagierten Ansatz für n-Tier-Architekturen, schon weiterhelfen. Einer der Vorteile ist, dass die Klasse ebenfalls von TDataSet erbt, so dass Du beliebige datenorientierte Controls (zB TDBGrid) mit der klientseitig gespeicherten Datenmenge verbinden kannst. Außerdem bietet die Klasse Grundfunktionalitäten zur Persistenzierung, Filterung, Aggregationsfunktionen, etc...

[bigg]

hi,

ein Array of Records.
Zum Darstellen der Datenbank empfiehlt sich VirtualTreeView.