Gibts eine schnelle TStringList mit Spalten?

[himitsu]

Zitat von alzaimar:

Es ist bestimmt nicht schwer, die TStringlist-Klasse um die zusätzlichen Funktionen zu erweitern.

Jupp, z.B. auch über die Class-Helper, falls man keine neue Klasse möchte.

Und zum Aufteilen gibt es unzählige Explodefunktionen.
(wobei da auch schnell was kleines selbstgebastelt ist)

[alzaimar]

Zitat von himitsu:

Jupp, z.B. auch über die Class-Helper, falls man keine neue Klasse möchte.

...Das wollte ich nicht vorschlagen, weil wir ja nicht die TStringList-Klasse erweitern, sondern eine gänzlich neue Klasse erstellen wollen/sollten/könnten.

[p80286]

Wenn ich richtig gelesen habe, soll am besten auch noch ein Index mitgeliefert werden.
Auf welche "Spalte(n)" ?
So sehr ich dagen bin, sich für 1000 Adresssätze gleich eine Embedded-DB zuzulegen, hier wäre dies wohl angebracht.

Zitat von moelski:

Und ich denke damit habe ich auch ein großes Problem : NameValueSeparator ...

Denn ich muss den Trenner angeben. Und genau das will ich nicht.

Bsp: Meine Rohdaten sind $GP12,23,34;35,6<CR>
Wenn jetzt der NameValueSeparator auf ; stehen würde ... Dann wird das kaum gut gehen.

Ach Ja ? und warum nicht? wenn wir mal von Unicode absehen, eins von den 250 Zeichen sollte doch wohl als "Fíeldseperator" brauchbar sein.



Grüße
K-H

[moelski]

Zitat:

wenn wir mal von Unicode absehen, eins von den 250 Zeichen sollte doch wohl als "Fíeldseperator" brauchbar sein.

Nein. Was da an Rohdaten ankommt kann alles mögliche sein. Da bleibt eben kein Trenner über.

Zitat:

Wenn ich richtig gelesen habe, soll am besten auch noch ein Index mitgeliefert werden.
Auf welche "Spalte(n)" ?

ein Index auf die Reihen würde genügen.

Zitat:

Embedded-DB

Ist aber vermutlich nicht so performant wie eine Lösung mittels einfacher Liste ...

[p80286]

Zitat von moelski:

Zitat:

wenn wir mal von Unicode absehen, eins von den 250 Zeichen sollte doch wohl als "Fíeldseperator" brauchbar sein.

Nein. Was da an Rohdaten ankommt kann alles mögliche sein. Da bleibt eben kein Trenner über.

Dann sollten wir uns ganz schnell von Strings verabschieden,und zu einem Binären Format wechseln. (und sei es ein mißbrauchter Shortstring)

Zitat von moelski:

Zitat:

Wenn ich richtig gelesen habe, soll am besten auch noch ein Index mitgeliefert werden.
Auf welche "Spalte(n)" ?

ein Index auf die Reihen würde genügen.

Im allgemeinen wird der Index aus den Daten gebildet, nach denen gesucht wird. Z.B. Name, Erfassungsdatum etc.
Die "Reihennr / Satznummer" kann man zwar auch indizieren, aber bei einer Suche nach Inhalten wäre das nicht sehr zielführend.

Zitat von moelski:

Zitat:

Embedded-DB

Ist aber vermutlich nicht so performant wie eine Lösung mittels einfacher Liste ...

Um eine DB zu schlagen, muß Du eine DB-Ähnliche Struktur erstellen!
Alleine das Erstellen dieser Struktur, (wie auch immer sie konkret aussieht) fällt im täglichen Betrieb der DB fort. Da hast Du nur noch eine Chance mit handoptimierten Algorithmen und viiieel Assembler. Ob das den Aufwand lohnt?

Gruß
K-H

[alzaimar]

Zitat von p80286:

Zitat von moelski:

Ist aber vermutlich nicht so performant wie eine Lösung mittels einfacher Liste ...

Um eine DB zu schlagen, muß Du eine DB-Ähnliche Struktur erstellen!...Da hast Du nur noch eine Chance mit handoptimierten Algorithmen und viiieel Assembler. Ob das den Aufwand lohnt?

Entschuldige, aber das ist Quatsch. So ziemlich jede interne (sortierte) Listenstruktur ist performanter als eine DB. Großartige Verrenkungen muss man noch nicht einmal anstellen: Eine sortierte Liste mit binary Search reicht vollkommen. Performancetechnisch total zerbröseln kann man jede DB mit einem Red-Black-Tree, einer Hashmap oder einer Kombination. Dafür muss man dann aber für jede Informationsabfrage einen neuen Algorithmus schreiben.

[Brainstalker]

Also hier die versprochene Datei. Ist aber glaub ich nicht so besonders brauchbar für dich. Kein Save und Load, ich dachte ich hätte damals mehr implementiert.

[Neumann]

Hallo,

warum nicht ein ClientDataset benutzen? Kann Speichern, Lesen, man Sortierkriterien festlegen. Bei Daten in einer Tabelle ideal.

Gruß

Ralf

[p80286]

Zitat von alzaimar:

Zitat von p80286:

Zitat von moelski:

Ist aber vermutlich nicht so performant wie eine Lösung mittels einfacher Liste ...

Um eine DB zu schlagen, muß Du eine DB-Ähnliche Struktur erstellen!...Da hast Du nur noch eine Chance mit handoptimierten Algorithmen und viiieel Assembler. Ob das den Aufwand lohnt?

Entschuldige, aber das ist Quatsch. So ziemlich jede interne (sortierte) Listenstruktur ist performanter als eine DB. Großartige Verrenkungen muss man noch nicht einmal anstellen: Eine sortierte Liste mit binary Search reicht vollkommen. Performancetechnisch total zerbröseln kann man jede DB mit einem Red-Black-Tree, einer Hashmap oder einer Kombination. Dafür muss man dann aber für jede Informationsabfrage einen neuen Algorithmus schreiben.

Okay geschenkt, ich war zu "Listenfixiert". Aber was bitte ist ein "Red-Black-Tree"? (der Wikipediaartikel ist mir zu farblastig). Mir sind nur die "Nil"-Blätter aufgefallen.

Gruß
K-H

[Satty67]

In C# bin ich dabei mit ein ObjectTable als Basis für ein nachgebautes StringGrid zu entwerfen. Das ist genauso leicht in Delphi realisierbar.

Es ist im Prinzip eine einfach Klasse mit dem Member
FObjectColumns = array of TObjectList; .
auf Strings spezialisiert könnte man
FStringColumns = array of TStringList nehmen.

Dabei ist jede Spalte eine TStringlist, lässt sich sehr einfach verwalten und um weitere Spalten erweitern. Zugriff erfolgt wie bei StringGrid via

Delphi-Quellcode:

function Cell(row, column : Integer): String;
begin
  sl := FStringColumns[column];
  result := sl[row];
end;

Also zumindest eine Basis-Funktionalität mit Get/SetCell und dynamischer Anpassung der Reihen/Spalten ist recht fix gemacht

PS: Wenn es interessant ist, kann ich heute Abend schnell eine Basisklasse schreiben, die Logik kann ich ja aus dem fertigen Code in C# übernehmen und muss nicht mehr viel dabei denken...