ListView > VST: wieviele Klassen verträgt ein Programm/VST

[mensch72]

VST = (grob) ein IndexPerElement, wo DU SELBST per GetValue/SetValue Event alles nötge live liefern, bzw speichern musst.

Kümmere dich also um eine saubere interne eigene Datenhaltung. Wenn du alles im Ram halten kannst dann mach es.. eine TObjektlist oder doch besser ein Dictionary also "KeyIndex for TObject" ist da ein erster Ansatz. Wenn eh nicht alle in den Ram passt, dann besser gleich die Daten Live per SQL aus einer indexbasierten Query geholt und auch per Index über Insert/Update Live aktualisiert.


Tip: Vergiss besser dein "INI" Konzept, wenn dann aktuell sowas als TObject<->JSON (Objekt)Serialisierung am besten mit aktuellem Delphi realisieren, sonst die RTTI dazu benutzen.
Satt purer INI Files oder HandMade XML dann lieber ne Mini (SQL)DB mit nem Index und nem Blob für die typisierten (Class)ObjectData als JSON.

[Glados]

Zitat:

Wenn du alles im Ram halten kannst dann mach es..

Genau das frage ich oben doch, denn ich weiß nicht wieviel das an RAM belegen würde.

Zitat:

Tip: Vergiss besser dein "INI" Konzept

Meinst du damit die Datenhaltung in Ini-Dateien? Nein. Dabei bleibe ich. Ich halte nix von fast kryptisch anmutenden Dateien, die die Nutzer ggf. nicht selber mit Notepad bearbeiten können.
Das ist aber nicht das Thema und hat für mich 0 Wichtigkeit.

Wichtig sind nur die beiden von mir gestellten Fragen für mich + wieviel RAM bei ~300 Bytes pro Ini-Section, ein paar Strings, Integers und Enums und das alles maximal 100x reserviert werden könnte.
Es sind keine komplexen Datentypen dabei.

[mensch72]

Ich denke Du und deine Kunden seid eventuell doch durchaus leicht anpassungsfähig
- selbst in einer Ini Datei kannst du per Section weiter einen "Key" und ein "(JSON)Value" als String speichern
- das kann man wenn man möchte jederzeit weiter per simplen Notepad als Texteditor bearbeiten
- die "automatisierte" ObjectSerialisierung wäre doch mal was "besonderes", denn das macht dir das Leben und den Source einfacher
- Ob nun ein Blob in einer SQL DB, oder eine ValueEintrag in einer Ini-Section... das ist doch völlig wurscht!

[Glados]

Welche Kunden? Hab ich keine.
Bitte lasst das Thema Ini sein. Das interessiert mich doch gar nicht und ich werde nichts anderes verwenden.

[mensch72]

jo, wir haben auch noch ein paar INIs das is schon weiter ganz praktisch

Also nochmal:
willst du unbeding weiter selbst KeyValuePerKeyValue für deine IniSections programmieren, oder haste nicht mal Lust dir da eventuell das Leben etwas zu erleichtern.
Versuch macht Kluch... probiere doch einfach mal was raus kommt und ob das noch für dich akzeptabel per Texteditor zu bearbeiten ist.

Die Bytes per Eintrag sind in deinen genannten Anzahlen heutzutage völlig wurscht!

[Glados]

Zitat:

willst du unbeding weiter selbst KeyValuePerKeyValue für deine IniSections programmieren, oder haste nicht mal Lust dir da eventuell das Leben etwas zu erleichtern.

Keine Lust Ich bleibe vorerst bei Ini. Das ist einfach genug.

Zitat:

probiere doch einfach mal was raus kommt und ob das noch für dich akzeptabel per Texteditor zu bearbeiten ist.

Ich brauche nichts auszuprobieren. Mit dem Ini-Format habe ich das für mich akzeptable Format gefunden.

Zitat:

Die Bytes per Eintrag sind in deinen genannten Anzahlen heutzutage völlig wurscht!

Was könnte denn da auf mich zukommen? 10, 20, 30, ... 100 MB im "Taskmanager" nach Programmstart bei 100 VST-Einträgen?

[hoika]

Hallo,
da du ja extrem beratungsresistent bist.

Warum probierst du deinen Ansatz nicht einfach aus?