Darstellung flexibler Daten

**BugFix**

Ich umschreibe es mal allgemein:

Ich habe eine Anzahl (<200) Artikel mit differierenden Eigenschaften. Wenn ich den Artikel anzeige, möchte ich dessen Eigenschaften darstellen. Das können 10 aber auch 30 Eigenschaften sein.

Mein erster Gedanke war das Erfassen in einer SQLite DB.
Für jede Eigenschaft ein Feld - führt zu Leerfeldern bei geringer Anzahl von Eigenschaften und ist nicht flexibel, wenn ein Artikel hinzukommt mit einer größeren Anzahl Eigenschaften.

Somit favorisiere ich jetzt je Artikel eine Datei (Dateiname=Artikelnummer) mit Inhalt Eigenschaft=Wert. Und nur den Dateilink mit einem weiteren Feld 'Tags', das alle Eigenschaftsnamen beinhaltet, hinterlege ich in einer DB. Somit kann ich auch gezielt Artikel mit bestimmten Eigenschaften suchen.

Meine Frage zielt auf die optische Darstellung.
Der einfachste Weg: Listview. Geringster Aufwand, alles sicht- bzw. scrollbar.
Der nach meinem Geschmack "schönere" Weg: Je Eigenschaft <Label-Eigenschaft> <Input_RO-Eigenschaftswert>. Etwas aufwändiger.

Wie würdet ihr es machen?

**Gun-Food**

Hmm.

Auch wenn ich den Hintergrund verstehe, würde ich alles in die DB packen. Die Suche ist schneller und flexibler und die Pflege für Dritte wird nachvollziehbarer, da alle mit Datenbanken was anfangen können. Zudem sind Dateien für mich immer störanfälliger. Wie schützenswert sind die Informationen?

Die Entscheidung würde ich allerdings auch nach der Herkunft der Informationen ausrichten. Kommen die als Datei, dann muss ich sie nicht anpassen. Kommen sie aus anderen Systemen, kann ich sie vielleicht direkt in eine DB schreiben.

So viele Gedanken

Guten Morgen

gmmg

das sagt die KI dazu.

Für dein Vorhaben gibt es eine sehr elegante Lösung, die sowohl dein Datenbank-Problem löst als auch die optische Darstellung dynamisch und modern gestaltet.

Der beste Ansatz für die Daten (EAV-Modell)

Nutze weiterhin SQLite, aber verwende das Entity-Attribute-Value (EAV) Modell anstelle von Textdateien. Das ist der Standard für Produkte mit flexiblen Eigenschaften. Du benötigst nur zwei Tabellen:

Artikel: ArtikelID, Artikelnummer, Name
Eigenschaften: ArtikelID, EigenschaftsName, EigenschaftsWert

Vorteil: Keine leeren Felder, unendlich flexibel, rasend schnell durchsuchbar (besser als Textdateien) und extrem leicht in AutoIt abzufragen.

Die optische Darstellung: Der "schönere" Weg (Dynamische GUI)

Ein ListView ist funktional, wirkt aber oft altbacken. Da du maximal 30 Eigenschaften pro Artikel hast, ist eine dynamische GUI mit Labels und Inputs absolut performant und optisch überlegen.

Du musst die Controls nicht manuell erstellen. Erzeuge sie stattdessen dynamisch per Schleife basierend auf den Eigenschaften des ausgewählten Artikels.

Hier ist ein einfaches, funktionsfähiges AutoIt-Beispiel, wie du so eine dynamische Anzeige umsetzt:

autoit

C

#include <GUIConstantsEx.紐>
#include <WindowsConstants.au3>
#include <ScrollBarsConstants.au3>

; Beispiel-Datenstruktur (wäre real dein SQLite-Abfrageergebnis)
Dim $aProps[12][2] = [ _
    ["Farbe", "Blau"], ["Größe", "XL"], ["Gewicht", "450g"], _
    ["Material", "Baumwolle"], ["Hersteller", "ACME Corp"], ["Garantie", "2 Jahre"], _
    ["Anschluss", "USB-C"], ["Spannung", "5V"], ["Zustand", "Neu"], _
    ["Lagerort", "Regal 4"], ["EAN", "401234567890"], ["Preis", "19,99 €"] _
]

$hGUI = GUICreate("Artikel-Eigenschaften", 400, 300)
GUISetState(@SW_SHOW)

; Zeige die Eigenschaften an
_ShowProperties($hGUI, $aProps)

Do
    $msg = GUIGetMsg()
Until $msg = $GUI_EVENT_CLOSE

Func _ShowProperties($hParent, $aData)
    Local $iTop = 20
    Local $iLeftLabel = 20
    Local $iLeftInput = 150
    Local $iRowHeight = 30

    ; Schleife durchläuft alle existierenden Eigenschaften des Artikels
    For $i = 0 To UBound($aData) - 1
        ; Erstelle Label für den Namen der Eigenschaft
        GUICtrlCreateLabel($aData[$i][0] & ":", $iLeftLabel, $iTop + ($i * $iRowHeight), 120, 20)
        
        ; Erstelle schreibgeschütztes Input-Feld für den Wert
        GUICtrlCreateInput($aData[$i][1], $iLeftInput, $iTop + ($i * $iRowHeight) - 4, 200, 20, 0x0800) ; 0x0800 = $ES_READONLY
    Next
EndFunc

Alles anzeigen

Verwende Code mit Vorsicht.

Profil-Tipps für die Umsetzung:

Das Scrollbar-Problem: Wenn ein Artikel 30 Eigenschaften hat, passt das nicht mehr in ein kleines Fenster. Erstelle in AutoIt ein Child-Fenster mit Scrollbars (_GUICtrlScrollbar_Create) innerhalb deiner Haupt-GUI. So bleibt deine Maske kompakt, aber der Nutzer kann sanft durch die 30 Inputs scrollen.
Alternative "Gegenstands-Ansicht" (PropertyGrid): Wenn du den ListView-Aufwand mit der Input-Optik kombinieren willst, schaue dir im AutoIt-Forum das UDF _GUICtrlPropertyGrid an. Das sieht aus wie die Eigenschafts-Leiste in Entwicklungsumgebungen (links Name, rechts Wert) und scrollt automatisch.

Ich würde dir definitiv zum EAV-Datenbankmodell + dynamischen Labels/Inputs mit Scrollbar raten. Das fühlt sich für den Endnutzer an wie eine professionelle Software.

Hier ist ein vollständiges, praxisnahes AutoIt-Beispiel, das zeigt, wie du das EAV-Modell (Entity-Attribute-Value) in SQLite aufbaust, Daten abfragst und für einen bestimmten Artikel ausgibst.

In diesem Setup speichert die Datenbank nur die Eigenschaften, die ein Artikel wirklich besitzt. Es gibt keine leeren Spalten (NULL-Werte) und du bleibst maximal flexibel.

AutoIt & SQLite: Das EAV-Beispiel

Kopiere diesen Code direkt in Scite. Er erstellt eine Datenbank im Arbeitsspeicher (:memory:), befüllt sie mit Testdaten und zeigt dir, wie einfach die Abfrage ist.

autoit

C

#include <SQLite.au3>
#include <SQLite.dll.au3>
#include <Array.au3>

; 1. SQLite initialisieren
_SQLite_Startup()
If @error Then Exit MsgBox(16, "Fehler", "SQLite.dll konnte nicht geladen werden!")

; Datenbank im Arbeitsspeicher erstellen (für den Test)
Local $hDB = _SQLite_Open() 

; 2. EAV-Tabellenstruktur erstellen
; Tabelle 1: Die Hauptartikel (Entities)
_SQLite_Exec($hDB, "CREATE TABLE tbl_Artikel (ArtikelID INTEGER PRIMARY KEY AUTOINCREMENT, Artikelnummer TEXT UNIQUE, Name TEXT);")

; Tabelle 2: Die dynamischen Eigenschaften (Attributes & Values)
; FOREIGN KEY sorgt dafür, dass Eigenschaften gelöscht werden, wenn der Artikel gelöscht wird.
_SQLite_Exec($hDB, "CREATE TABLE tbl_Eigenschaften (" & _
                   "EigenschaftID INTEGER PRIMARY KEY AUTOINCREMENT, " & _
                   "ArtikelID INTEGER, " & _
                   "EigenschaftsName TEXT, " & _
                   "EigenschaftsWert TEXT, " & _
                   "FOREIGN KEY(ArtikelID) REFERENCES tbl_Artikel(ArtikelID) ON DELETE CASCADE);")

; 3. Testdaten einfügen
; Artikel 1: Ein T-Shirt (hat Textil-Eigenschaften)
_SQLite_Exec($hDB, "INSERT INTO tbl_Artikel (Artikelnummer, Name) VALUES ('ART-001', 'Laufshirt Pro');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (1, 'Farbe', 'Blau');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (1, 'Größe', 'XL');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (1, 'Material', 'Polyester');")

; Artikel 2: Ein USB-Ladegerät (völlig andere technische Eigenschaften)
_SQLite_Exec($hDB, "INSERT INTO tbl_Artikel (Artikelnummer, Name) VALUES ('ART-002', 'USB-C Ladeadapter');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (2, 'Spannung', '20V');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (2, 'Leistung', '65W');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (2, 'Anschlüsse', '2x USB-C');")
_SQLite_Exec($hDB, "INSERT INTO tbl_Eigenschaften (ArtikelID, EigenschaftsName, EigenschaftsWert) VALUES (2, 'Farbe', 'Schwarz');") ; Gleiche Eigenschaft wie oben, anderer Wert


; 4. PRAXIS-ANWENDUNG: Eigenschaften eines bestimmten Artikels laden
Local $sSuchArtikelnummer = "ART-002" ; Hier deine gewünschte Artikelnummer eintragen

Local $aResult, $iRows, $iColumns
Local $sSQL = "SELECT e.EigenschaftsName, e.EigenschaftsWert " & _
              "FROM tbl_Eigenschaften e " & _
              "JOIN tbl_Artikel a ON e.ArtikelID = a.ArtikelID " & _
              "WHERE a.Artikelnummer = " & _SQLite_FastEscape($sSuchArtikelnummer) & ";"

If _SQLite_GetTable2d($hDB, $sSQL, $aResult, $iRows, $iColumns) = $SQLITE_OK Then
    ; $aResult enthält nun ein 2D-Array mit allen existierenden Eigenschaften
    ; Zeile 0 enthält die Spaltenüberschriften, ab Zeile 1 liegen die Daten
    _ArrayDisplay($aResult, "Eigenschaften für " & $sSuchArtikelnummer)
Else
    MsgBox(16, "Fehler", "Fehler bei der Datenbankabfrage.")
EndIf

; 5. Datenbank schließen
_SQLite_Close($hDB)
_SQLite_Shutdown()

Alles anzeigen

Verwende Code mit Vorsicht.

Die Vorteile dieses SQL-Setups für dein Projekt:

Dynamisches Array für deine GUI: Das Ergebnis-Array $aResult (wenn du Zeile 0 ignorierst) hat exakt das Format, das die dynamische GUI-Schleife aus der ersten Antwort benötigt ($aResult[$i][0] = Name, $aResult[$i][1] = Wert). Du übergibst das Array einfach an deine Anzeigefunktion.
Gezielte Suche (Dein "Tags"-Gedanke): Wenn du alle Artikel suchst, die z.B. die Eigenschaft Farbe = Blau haben, schreibst du einfach:
sql
SQL
```
SELECT ArtikelID FROM tbl_Eigenschaften WHERE EigenschaftsName = 'Farbe' AND EigenschaftsWert = 'Blau';
```
Verwende Code mit Vorsicht.
Keine Daten-Redundanz: Wenn du morgen ein neues Produkt mit 50 völlig neuen Eigenschaften (z.B. "Akkukapazität", "Profiltiefe") hinzufügst, musst du keine Tabellenstruktur in der DB ändern. Du fügst sie einfach als neue Zeilen in tbl_Eigenschaften ein.