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: