Standardlösung zur Lagerung von Maßeinheiten

EINLEITUNG UND RELEVANTE INFORMATIONEN:

Nehmen wir an, ich habe einen Tisch, an dem Größe und Gewicht einer Person gespeichert sind.

PersonTable < # ID int, Name varchar(50), Height double, Weight double >

Die Höhe wird in Zentimetern und das Gewicht in Kilogramm gemessen.

PROBLEM:

Mein Problem ist die Speicherung der Maßeinheit für Größe und Gewicht.

Meine Bemühungen, dies zu lösen:

PersonTable < # ID int, 
                Name varchar(50), 
                Height double, $ HeightUnit_Id int, 
                Weight double, $ WeightUnit_Id int >

Units < #ID int, Desription varchar(20) >

HeightUnit_Id und WeightUnit_Id sind Fremdschlüssel, die auf die ID aus Tabelleneinheiten verweisen.

FRAGE:

Gibt es eine bessere Lösung als die offensichtlichen, die ich oben erwähnt habe, da ich beide nicht mag (EAV kann unordentlich werden, wenn es schlecht gemacht wird, und das Hinzufügen zusätzlicher "Einheitenspalten" scheint mir eine Verschwendung von Platz zu sein)?

Angenommen, die Messtypen werden nicht gemischt (dh eine bestimmte Zeile mischt nicht "kg" und "Zoll" ODER "Pfund" und "cm"), und es wird auch angenommen, dass sich zumindest ein Teil der Absicht dieser Frage jetzt darauf bezieht gelöschte verwandte Frage ( bitte beachten Sie, dass der folgende Link nur funktioniert, wenn Sie über genügend Wiederholungspunkte verfügen, um gelöschte Elemente anzuzeigen : Behandeln von zusammengesetzten Attributen mit konstantem Teil ), müssen Sie nur das von dieser Zeile verwendete Messsystem angeben . In diesem Modell hätten Sie eine einzelne MeasurementSystemTabelle mit Fremdschlüssel für alle Tabellen, die Messungen enthalten. Zum Beispiel (unter Verwendung der Microsoft SQL Server-Syntax):

CREATE TABLE dbo.MeasurementSystem
(
  MeasurementSystemID TINYINT NOT NULL
                      CONSTRAINT [PK_MeasurementSystem] PRIMARY KEY
                                 CLUSTERED,
  MeasurementSystemName NVARCHAR(50) NOT NULL
);

dbo.Person
(
  PersonID            INT NOT NULL IDENTITY(1, 1)
                      CONSTRAINT [PK_Person] PRIMARY KEY
                                 CLUSTERED,
  MeasurementSystemID TINYINT NOT NULL
                      CONSTRAINT [FK_Person_MeasurementSystem]
                      FOREIGN KEY
                      REFERENCES dbo.MeasurementSystem (MeasurementSystemID),
  Name                NVARCHAR(50) NOT NULL
  Height              FLOAT,
  Weight              FLOAT,
  ...
);

INSERT INTO dbo.MeasurementSystem (MeasurementSystemID, MeasurementSystemName)
VALUES (1, N'Metric');

INSERT INTO dbo.MeasurementSystem (MeasurementSystemID, MeasurementSystemName)
VALUES (2, N'United States customary units');

Wenn Sie Messsysteme mischen und / oder mehrere Maßeinheiten zulassen, auch wenn diese auf ein System beschränkt sind (dh "mm", "cm", "m"), muss eine vorhanden sein zusätzliche Ebene, um die Zunahme der Granularität zu bewältigen, einschließlich der Notwendigkeit, ein FK-Feld pro Messspalte in der PersonTabelle zu haben. (Ich kann das obige Modell anpassen, aber ich werde auf eine Klarstellung warten, bevor ich dies tue).

Wenn es eine relativ begrenzte Anzahl von Kombinationen verschiedener Gewichts- und Höheneinheiten gibt, können Sie stattdessen jede Zeile verwenden, um eine der akzeptierten Kombinationen darzustellen (z. B. "cm & kg", "m & kg"). "mm & kg" / "inch & lb", "foot & lb"). Und dann ist "US" vs "Metric" nur eine Eigenschaft jeder Zeile der Nachschlagetabelle. Zum Beispiel:

CREATE TABLE dbo.MeasurementUnit
(
  MeasurementUnitID     TINYINT NOT NULL
                                CONSTRAINT [PK_MeasurementUnit] PRIMARY KEY
                                           CLUSTERED,
  MeasurementSystem     CHAR(1) NOT NULL, -- "M" = Metric, "U" = US 
  MeasurementSystemName NVARCHAR(50) NOT NULL, -- "Metric" or "US Nonsense"
  HeightUnitsName       NVARCHAR(20) NOT NULL, -- "Centimeters"
  HeightUnitsAlias      NVARCHAR(5) NOT NULL, -- "cm"
  WeightUnitsName       NVARCHAR(20) NOT NULL, -- "Kilograms"
  WeightUnitsAlias      NVARCHAR(5) NOT NULL -- "kg"
);

dbo.Person
(
  PersonID            INT NOT NULL IDENTITY(1, 1)
                      CONSTRAINT [PK_Person] PRIMARY KEY
                                 CLUSTERED,
  MeasurementUnitID   TINYINT NOT NULL
                              CONSTRAINT [FK_Person_MeasurementUnit]
                                         FOREIGN KEY
                                        REFERENCES dbo.MeasurementUnit (MeasurementUnitID),
  Name                NVARCHAR(50) NOT NULL
  Height              FLOAT,
  Weight              FLOAT,
  ...
);

Oder wenn es Kombinationen von Einheiten geben muss, die verschiedene Messsysteme kreuzen, würde ich separate Tabellen verwenden - eine für jeden Messtyp: "WeightUnits" und "HeightUnits". Ich würde keine Einheiten für Höhen und Gewichte in derselben Tabelle mischen (dh "kg" und "cm" in verschiedenen Reihen). Zum Beispiel:

CREATE TABLE dbo.WeightUnit
(
  WeightUnitID      TINYINT NOT NULL
                            CONSTRAINT [PK_WeightUnit] PRIMARY KEY
                                       CLUSTERED,
  MeasurementSystem CHAR(1) NOT NULL, -- "M" = Metric, "U" = US 
  WeightUnitName    NVARCHAR(50) NOT NULL, -- "Kilograms"
  WeightUnitAlias   NVARCHAR(5) NOT NULL -- "kg"
);

CREATE TABLE dbo.HeightUnit
(
  HeightUnitID      TINYINT NOT NULL
                            CONSTRAINT [PK_HeightUnit] PRIMARY KEY
                                       CLUSTERED,
  MeasurementSystem CHAR(1) NOT NULL, -- "M" = Metric, "U" = US 
  HeightUnitName    NVARCHAR(50) NOT NULL, -- "Centimeters"
  HeightUnitAlias   NVARCHAR(5) NOT NULL -- "cm"
);

In diesem Modell hat jeder Messtyp in einer bestimmten Tabelle eine eigene persönliche FK für die Nachschlagetabelle der Maßeinheiten.

Angesichts der Frage, wie sich diese Frage auf das Design bezieht, sind die Antworten wahrscheinlich ziemlich einfühlsam ...

Hier ist meine Meinung dazu, wie es gestaltet werden soll. ;)

Tabelle zum Speichern von Maßeinheiten

CREATE TABLE measure_unit (
  measure_unit_id, -- primary key
  name -- unique key .. values such as "inch" etc
)

Ihr Personentisch ...

CREATE TABLE person (
  person_id, -- primary key
  name,
  measurement, -- example values would be 180
  measure_unit_id -- example values would be the pkey for centimeters
)

Und dann eine Umrechnungstabelle

CREATE TABLE measure_conversion (
  from_measure_unit_id, -- example would be pkey for centimeters
  to_measure_unit_id, -- example would be pkey for inches
  ratio -- example would be 0.393701 (centimeters * 0.393701 = inches)
  -- pkey is composite between both from and to values
)

Wenn eine Maßeinheit keinen Eintrag in der Kennzahlenumrechnungstabelle für einen bestimmten anderen Einheitentyp hat, ist keine direkte Umrechnung verfügbar. (Zum Beispiel würde cm -> Zoll funktionieren, cm -> Stunden jedoch nicht.) Die Anzeige Ihrer Messungen in verschiedenen Einheiten sollte einfach sein.

Ihre Maßeinheit kann alles sein, was Sie wollen (Entfernung / Zeit / usw.) ... aber Sie möchten möglicherweise einen Maßtyp hinzufügen. Sie sind sich nicht sicher, ob ich mir darüber Sorgen machen würde - hängt vom Anwendungsfall ab.

Wenn Ihre Größen- / Gewichtsmaßeinheiten tatsächlich fest sind , dh Größe = CMs, Gewicht = KGs, würde ich keine zusätzlichen Spalten (oder Logik) einführen, um die Maßeinheit anzugeben. Stattdessen würde ich einfach den Spaltennamen ändern, z

create table Person (ID int, Name varchar(50), Height_CM double, Weight_KG double)

Auf diese Weise kann ich alle Verwirrungen über die Maßeinheit für Spalten Höhe und Gewicht beseitigen.

Dies hängt davon ab, was Sie entwerfen. Ein normalisiertes OLTP-System verfügt über eine separate Measures-Tabelle (oder einen solchen Namen), die für jede mögliche Maßeinheit referenzielle Integritäts- und Leistungsoptimierungen bietet.

Wenn Sie Analysen durchführen und selten mit Einheiten arbeiten und weniger Konvertierungen durchführen, kann dies als Attribut gespeichert werden. Dies wäre immer noch selten - so etwas wie Umfrageantworten oder ein Industriestandard wie Quadratmeter für Immobilien. Aber was wird sonst noch gemessen und macht bei Immobilien Sinn? Grundrisse? Jetzt haben wir Zoll ... und Quadrate und Kubik. Wir sind zurück zu einem normalisierten Design.

Für die Höhe sind verschiedene Maßnahmen anwendbar, die in verschiedenen Zusammenhängen durchaus sinnvoll sind. Wahrscheinlich eine gute Idee, ein Design wie dieses zu verwenden:

dbo.PersonHeight
Height     MeasureFK
62           2

dbo.UnitsOfMeasure
MeasureID  MeasureDescription
2          Inches
3          Centimeters

Mit einem solchen Design können Sie jetzt ganz einfach eine Nachschlagetabelle erstellen:

dbo.UnitConversions
FromMeasureID    ToMeasureID    Conversion
2                 3             0.39370079