[erledigt] Wie Maßeinheiten in Datenbank speichern?

[Jorg3000]

Moin!
Meine Frage ist erst mal nur theoretischer Natur, ich habe noch keinen Quellcode.

Angenommen ein Benutzer kann in ein Formular einen Wert eingeben und dazu eine Maßeinheit auswählen - ein wählbares Vielfaches, z.B. Milligramm, Kilogramm oder Kilotonne.
Würdet ihr den Eingabewert auf eine Basiseinheit umrechnen, z.B. in Gramm, und als Fließkommazahl speichern
ODER - und jetzt kommt das was mich eigentlich interessiert - würde man die vom Nutzer gewählte Einheit in einer zusätzlichen Spalte speichern?

Wenn ich dem Benutzer später jede Eingabe in der von ihm jeweils ausgewählten Einheit wieder anzeigen möchte, müsste ich die pro Eingabe ausgewählte Einheit sowieso irgendwo speichern.

Meine eigentliche Frage: Wie speichert man Maßeinheiten (bzw. die abgeleitete Größe) am besten?
Jeweils als sprechenden String, z.B. "mg", "kg", "kt" oder lieber in einer Konstante wie 1, 2, 3 ... ?
Würde man Zahlenkonstanten in seiner Anwendung nach Lust und Laune selber definieren oder gibt es eine ISO-Norm o.ä. für Zahlenkonstanten für Größeneinheiten? Oder vielleicht schon eine fertige Pascal-Unit?
Oder gibt es dafür sogar einen Datenbank-Standard von der Stange, oder bastelt sich jeder Programmierer etwas nach eigenem Bedarf und Gutdünken selbst? (was ich vermute)

Noch kniffliger wird es bei seltenen Zeitangaben: Tag.Monat.Jahr mit und ohne Uhrzeit, oder nur Monat/Jahr (z.B. Baujahr), oder "Mitte des 17. Jahrhunderts", oder 2.500 Jahre v.Chr., oder "vor ca. 100 Millionen Jahren" (mya = million years ago).
Vermute ich richtig, dass man solche Spezialangaben entweder als interpretierbaren String in die Datenbank speichern würde oder sich einen komplexen Datentyp selber bauen würde, den man entweder als Binärobjekt oder zerlegt auf mehrere Spalten verteilt speichern würde?

Ich frage deshalb, weil ich das noch nie gemacht habe und ich mir später nicht anhören möchte: "Warum hast du das denn nicht einfach mit der XYZ-Funktion gemacht, da ist doch alles schon drin!"

Danke fürs Lesen. Ich freue mich auf Kommentare.
Grüße, Jörg

[af0815]

Antwort von Radio Eriwan: Es kommt darauf an.

Wenn es möglich ist, lasse ich den Benutzer etwas auswählen, nicht angeben. Daher zB. beim Datum/Zeit, Zahlen, Einheiten einen entsprechenden Dialog. Speichern tue ich normalerweise immer das was der Benutzer eingibt und rechne erst dann um, wenn ich es brauche. Es hängt auch davon ab, was ich mit den Daten in der DB machen will. Wieviel Speicher mir redundante Daten kosten, muss ich beim DB-Design über die vermutete Laufzeit sowieso kalkulieren. Die Daten müssen ja einen Zweck haben und den mit der Verarbeitung sollte ich mir vorher überlegen.

oder "Mitte des 17. Jahrhunderts", oder 2.500 Jahre v.Chr., oder "vor ca. 100 Millionen Jahren"

Das ist was was man maximal als Zusatz zur Anzeige speichern kann, aber was willst du in einer DB machen. Es gibt keinen 'Cirka' Vergleich und bei den Daten würde ich keine TDateTime verwenden

Nein, das wichtigste ist, du hast ein gutes Konzept und reduzierst auf native Datentypen. Was anderes ist sowieso nicht möglich. Vorher planen ist besser als nachher herumfrickeln.

[Joh]

Da man häufig unterschiedliche Einheiten hat:
Tabelle mit Maßeinheiten

Code: Alles auswählen

id   Einheit kurz   Einheit lang
 1        kg        Kilogramm
 2        m         Meter   
 3        Stck.     Stück

Das diszipliniert auch bei der Eingabe: m, m., mtr., Meter und viele Flascheingaben werden vermieden.

und Verweis auf id...
Beim Datum macht man das meistens so, das entweder das Datum als Datum und zusätzlich ein String gespeichert wird,

[Jorg3000]

Danke schon mal für eure Antworten!
Also scheint Selberbauen angesagt zu sein, wie ich vermutet hatte.
Ich wollte sicherstellen, dass ich mir die Arbeit nicht unnötig mache und dabei einen bestehenden Standard übersehe oder an einer vorhandenen Implementierung vorbei programmiere. Das wäre doppelt ärgerlich.

Zwischenzeitlich habe ich einen Blick in die Units StdConvs und ConvUtils geworfen, weil ich vermutete, dass darin Maßeinheiten als Konstanten definiert sein könnten.
Zu meiner Überraschung gibt es darin nur Konstanten als Umrechnungsfaktoren und als englischsprachige Strings, aber keine Maßeinheit-IDs als Zahlen-Konstanten.

Ja gut, dann scheint es diesbezüglich keine festgelegten Programmier-Standards zu geben, und jeder baut sich seine eigene ID-Tabelle, wie in Joh's o.g. Beispiel.
Danke und Grüße, Jörg

[Socke]

Solange du das in Pascal und nicht in der DB umsetzen möchtest, empfehle ich dir pro Basiseinheit eine Konvertierungsklasse. Die Umrechnung zwischen unterschiedlichen Basiseinheiten ergibt in der Regel wenig Sinn.

Wenn du die Umrechnung in der Datenbank umsetzen willst, erweiterst du deine Einheitentabelle um die Umrechnungsfaktoren:

Code: Alles auswählen

id	Einheit	Basiseinheit	Faktor  Langtext
 1	kg	kg		1	Kilogramm
 2	g	kg		0,001	Gramm
 3	t	kg		1000	Tonne

Aufwändiger wird es bei variablen Umrechnungsfaktoren, wie sie in der Logistik häufig auftreten:
Beim Artikel "Nudeln" passen 20 Packungen in einen Karton und 20 Kartons auf eine Palette.
Beim Artikel "Joghurt" hast du hingegen 10-30 Becher in einem Tray oder Gläser in einem Rahmen, die beide auf der selben Palette stehen.

Damit kann man auch so schöne Fragen stellen: Wie viele Paletten benötige ich um einen Becher Joghurt zu versenden?

[Jorg3000]

Umrechnungen wollte ich in Pascal machen. Aber Danke für den Denkanstoß!