Die Frage an sich könnte auch heißen : "Was schmeckt besser : Äpfel, Birnen oder ein Record ?"
Was man machen kann, heißt noch lange nicht, daß man es machen muß oder sogar soll !! Records kommen aus dem Bereich Datenbank. Man mußte sich pro Datensatz eine Struktur ausdenken, die eben strukturiert ist. Z.B. ging es darum, ein Datum mit Tag, Monat und Jahr abzubilden. Wobei nur integer zur Verfügung stand. Deshalb ein Record mit 3 Untervariablen als integer. Später wurde das dann noch komprimiert usw.
Zu jedem Datum jetzt noch eigene Behandlungsroutinen mitzuschleppen und abzuspeichern ? Was soll das ? Das geht anders viel eleganter. Nun kommen noch Listen Arrays usw. ins Spiel. Gut, ich bleibe mal bei dem Datum : Ich speichere also in der
DB einen Monat als Zahl, z.B. 2 für Februar. Der Anwender will nun aber nicht die 2 haben, sondern das Wort "Februar". Was liegt da näher, als die Monatsnamen in einem Array zu speichern ?
Besteht der leiseste Zweifel daran, daß es demnächst nicht mehr 12, sondern 13 Monate oder mehr gibt, so würde ich auch Listen verwenden. Vorher aber nicht.
Lange Rede kurzer Sinn :
Überlegen, ob sich und wenn, dann was sich ändern kann. Bleibt alles so wie gehabt, dann Arrays, Records und ordinale Typen. Geht es ums speichern von Daten dann sowieso. Im Programm selber macht es aber schon Sinn eventuell mit Objekten zu hantieren. Wer nicht mal grundsätzlich
OOP einsetzt für ein etwas größeres Programm, der ist selber Schuld und kann letztenendes sowieso einpacken. Aber auch dann gilt, sich das genau zu überlegen, wo was nützlich ist.