Arbeiten mit Records

[DeddyH]

Wenn ich mal ausnahmsweise mit Records arbeite, komme ich im Normalfall ohne IDs aus: Records in eine Liste packen und dann über Indizes ansprechen. Die Pointer in der Liste sind ja eindeutig, da braucht es kein spezielles Feld im Record. Aber so etwas sollte man sich eben im Vorfeld überlegen, die Darstellung ist ja erst einmal zweitrangig.

[p80286]

Naja es kommt wie immer auf die Daten an. Wenn man z.b. Adressen hat und der Zugriff über den Familiennamen geht muß man entweder mehrere Datensätze als ergebnis akzeptieren, oder eben ein weiteres Feld (ID,Vorname....) zur Identifikation heranziehen.

Und da es hier jetzt ums Lernen geht, würde ich nicht mit einer DB arbeiten. Für ernsthafte Projekte wäre sie allerdings zu bevorzugen.

Gruß
K-H

[DeddyH]

Ob ich nun eine ID habe oder einen Array- bzw. Listenindex, welchen Unterschied macht das?

[p80286]

Es geht ja um die Identifikation des Datensatzes also den Inhalt. Wenn Du über einen Arrayindex zugreifst erwischst Du ja irgendwelche Daten die sich an dieser Position befinden.
Ich gehe jetzt mal davon aus, daß die gelesenen Daten nicht immer an der gleichen Position in Liste/Array auftauchen.
Wenn Du allerdings über einen Index auf die Daten zugreifst, dan mußt Du natürlich über den Array/Listen-Index kommen.

Gruß
K-H

[Furtbichler]

Zitat von DeddyH:

Ob ich nun eine ID habe oder einen Array- bzw. Listenindex, welchen Unterschied macht das?

Das merkst Du dann, wenn Du etwas aus der Liste entfernst oder einfügst. Der Instanzenzeiger ist nicht schlecht, aber beim Kopieren eines Records, z.B. zum Editieren mit der Möglichkeit, die Änderungen zu verwerfen, nicht mehr zu gebrauchen.

Davon abgesehen, das es einfach keine gute Idee ist, mit Records und Listen derartige Operationen durchzuführen, sollten Records einen Identifikator besitzen, so wie eigentlich jede Entität.

Aber davon abgesehen: Records? Nee.

[sx2008]

Kleine Entwicklungsgeschichte von dBase...

Am Anfang gab es nur Records mit fester Satzlänge (in Pascal/Delphi als typisierte Datei bekannt).
Dann tauchte aber schon das erste Problem auf:
wie kann man einen Datensatz mitten in der Datei löschen ohne dass man unter Unständen viele Megabytes in der Datei verschieben muss?
Die Lösung ist, dass das 1 Byte im Record den Löschstatus angibt.
' ' bedeutet Datensatz gültig
'*' bedeutet Datensatz gelöscht bzw. als gelöscht markiert

Irgendwann muss man die als gelöscht markierten Datensätze wieder entfernen.
Daher braucht man ein Tool, dass die Recordlänge und die Datei kennt und dann nur die nicht-gelöschten Records in eine neue Datei kopiert.
Das Problem dabei ist falls die Recordlänge nicht stimmt ist das Ergebnis nur noch Datenmüll.

Der nächste Entwicklungsschritt war also dass die Datei einen Header bekommt in dem die Recordlänge vermerkt ist.
Im Header wird zusätzlich aber noch eine Feldliste geführt.
Für jedes Feld wird der Feldname (max 10 Zeichen), Feldlänge, Datentyp (C=Character, N=Numerisch, D=Datum, L=Logisch/Boolean) und ggf. Anzahl der Nachkommastellen gespeichert.
Im Header stehen noch weitere Infos wie z.B. die dBase-Version, Datum der letzten Änderung, Anzahl Datensätze, Zeichensatz, ...
http://www.dbase.com/Knowledgebase/INT/db7_file_fmt.htm

Die Datenfelder werden aus der Software auch nicht mehr über ihre feste Position im Record sondern über ihren Feldnamen angesprochen.
Diese Technik war vor vielen Jahren revolutionär und hat dBase zur Erfolgsgeschichte gemacht.
Durch die Feldbeschreibung im Header konnte man z.B. neue Felder hinzufügen oder die Reihenfolge ändern ohne dass die Anwendungen damit ein Problem bekommen.

Das ist aber noch nicht alles.
Um Datensätze schnell aufzufinden wurde parallel zur dBase Datendatei noch eine oder mehrere Indexdateien geführt.
Ausserdem gab es noch eine weitere Datei in der Felder mit variabler Länge (Memo Felder) gespeichert wurden.

Was ich hier beschrieben habe ist Stand der Technik im Jahr 1985 und die war den alten typisierten Dateien weit überlegen.

[musicman56]

[OT]
@sx2008 Kann es sein, dass wir beide schon etwas älter sind, um nicht zu sagen, das MHD in greifbarer Nähe ist
[/OT]

[sx2008]

Zitat von musicman56:

[OT]
@sx2008 Kann es sein, dass wir beide schon etwas älter sind, um nicht zu sagen, das MHD in greifbarer Nähe ist
[/OT]

Könnte schon sein, aber der neuronale Rechner arbeitet noch ganz gut
Ich lerne z.Zt. nebenher Scala - das ist sehr heftig wenn man bislang nur objektorientierte Programmiersprachen wie Delphi oder C++ benützt hat.