September 26, 2020, 21:38:32

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Beratung zu Feldtypen

Begonnen von hajott, August 26, 2020, 07:38:41

⏪ vorheriges - nächstes ⏩

hajott

Liebe Wissende,
hallo alle ;-))

ich bitte mal um eure Beratung zu folgendem Thema. Ich soll eine Access-Anwendung gestalten, die am Ende rund 800.000 Datensätze hat. Damit die Größe und Bearbeitungsdauer auch bei einem lahmen Netzwerk im Rahmen bleibt, möchte ich den Entwurf der Datentabelle möglichst optimal konfigurieren.

Neben einigen unvermeidbaren Stringfeldern besteht der Aufbau aus einem Referenzfeld , einem Statusfeld und drei Datumsfeldern, um die es mir hier geht.

Das Referenzfeld sieht der Anwender als ABCDEF1234567, so will ich es aber nicht speichern, da A, B, D und E konstant sind. Die kann man auch an der Bedieneroberfläche rein- bzw. rausrechnen, also nur CF1234567.
Dort, wo das C steht, gibt es aber nur zwei Optionen, C und Q. Die sechste Stelle (F) kann jeder Großbuchstabe sein.

Meine Idee zur Optimierung ist, das F groß, bzw klein zu schreiben je nachdem, ob ein C oder Q vorangeht. So hätte ich die Referenznumner in nur einem Zeichen sowie einem Longint für den siebenstelligen Zahlenteil.

Der Status besteht aus einem Buchstaben, hier überlege ich, den nicht als String, sobdern als Byte zu speichern, kostet dann nur einen statt zwei Bytes. (Könnte man mit dem Buchstaben aus der Referenz genau so machen)

Die drei Datumsfelder enthalten Datumsangaben, die sich in der Gegenwart befinden. Uhrzeiten sind nicht vorhanden. Nun habe ich gelesen, dass auch Datum kurz 8 Byte frisst. Ich überlege hier, das Datum auf eine Integerzahl runterzurechnen (2 Bytes) damit bekommt man fast 90 Jahre abgedeckt, das reicht. (1.1.1970 = 1). Natürlich würde ich an der Oberfläche sicherstellen, dass keine Daten außerhalb des Zeitraums erfasst werden können.

Nun meine Frage an euch: Ist das sinnvoll oder paranoid? Braucht am Ende das System für die Umrechnung mehr als ich dabei gewinne?
Ich habe auch gehört, dass Access am liebsten mit LongInts arbeitet, würde meine Zersplitterung da mehr schaden als nutzen?
Und bei den Daten mache ich ja im Grunde den gleichen Fehler wie die Programmierer aus den Siebzigern, die Speicher sparen wollten, oder?

Aber zur Rechtfertigung: Die Zugriffe sind selten (Archivverwaltung) und unser Netzwerk ist wirklich seeehr lahm.

Vielen Dank im Voraus für eure Gedanken hierzu.

Hans-Jürgen

ebs17

August 26, 2020, 09:42:54 #1 Letzte Bearbeitung: August 26, 2020, 13:11:17 von ebs17
Die nachfolgende Bearbeitung sieht wie aus? Laden der ganzen Tabelle oder echte Verarbeitung (Filtern, Gruppieren, Verknüpfungen, richtige Abfragelogiken)?

Großes Thema für Performance ist Indexnutzung: Grundlagen - SQL ist leicht ( 8 ) - Index
Darauf aufbauend dann durchdachtes Abfragedesign - bei größeren Datenmengen schlagen nichtoptimale Zustände richtig spürbar durch.

Beim Referenzfeld würde man also atomare Informationen in getrennten Feldern speichern und recht oft auch so verarbeiten. Die Zusammenführung ist ja meist erst für eine Benutzeransicht oder für Exporte nötig.

Datumsfelder sollte man so lassen wie sie sind.
Mit freundlichem Glück Auf!

Eberhard

hajott

Hallo Eberhard,

autsch, das Thema Index hatte ich vergessen, vielen Dank für den Link. Und weil die Referenz hier sinnvoll zu indizieren ist, werde ich sie auch nicht weiter atomisieren.

Datumsfelder: Ich habe ja auch ein schlechtes Gefühl bei meinem Vorhaben, das zu kannibalisieren. Aber 3 x 8 Bytes sind doch was anderes als 3 x 2 Bytes. Könntest du nur für mich mir nochmal einen Hintergrund nennen, dass man Datenfelder so lassen sollte wie sie sind? (außer der Tatsache, dass sie nur für bestimmte Zeiträume genutzt werden dürfen)

Zur Verwendung: Anwender kommt immer über die Referenz, fragt ab, oder editiert einzelne Felder (letzteres ist selten, daher mache ich keine Normalisierung und Aufteilung auf verschiedene Tabellen). 99% ist ,,flach".

Viele Grüße

Hans-Jürgen

ebs17

ZitatDatenfelder so lassen sollte wie sie sind
Noch einmal der Index. Dieser ist nur nutzbar bei einem unveränderten Feldinhalt, weil darauf ist er erzeugt. Jede Berechnung auf den Inhalt lässt in Jet eine Indexnutzung sterben, das beginnt schon bei einem ...
Feld * 1
Not Feld
Feld <> "x"
ZitatAnwender kommt immer über die Referenz
Also braucht er jeweils genau einen Datensatz. Also könnte man das Formular leer starten und dann nur per indizierten Filter genau diesen Datensatz ins Frontend holen für Anzeige und Editierung.
Ein Datensatz ist selbstredend eine ganz andere Menge als die ganze Tabelle, und Deine Byte-Gedanken erübrigen sich. Es kommt vor allem darauf an, was man bewegt, viel weniger auf das, was man hat.
Mit freundlichem Glück Auf!

Eberhard

hajott

alles klar, vielen Dank !!!