solução padrão para armazenar unidades de medida

Assumindo que os tipos de medição não serão misturados (ou seja, nenhuma linha específica não irá misturar "kg" e "polegadas" OU "libras" e "cm"), e também assumindo que pelo menos parte da intenção desta Questão está relacionada a isso agora Pergunta relacionada excluída ( observe que o link a seguir não funcionará, a menos que você tenha pontos rep suficientes para ver os itens excluídos: Lidando com atributos compostos com parte constante ), então você só precisa indicar o sistema de medição usado por essa linha. Neste modelo, você teria uma única MeasurementSystemtabela com chave estrangeira para quaisquer tabelas contendo medições. Por exemplo (usando a sintaxe do Microsoft SQL Server):

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');

Se você estiver misturando sistemas de medição e/ou se estiver permitindo várias unidades de medição, mesmo se confinado a um sistema (ou seja, permitindo "mm", "cm", "m"), será necessário haver um camada adicional para lidar com o aumento da granularidade, incluindo a necessidade de ter um campo FK para cada coluna de medida na Persontabela. (Posso adaptar o modelo acima para se adequar a isso, mas aguardarei alguns esclarecimentos antes de fazê-lo).

Ou, se houver uma quantidade razoavelmente finita/limitada de combinações de várias unidades de peso e unidades de altura, você pode usar cada linha para representar uma das combinações aceitas (por exemplo, "cm & kg", "m & kg", "mm & kg" / "pol e lb", "pé e lb"). E então "US" vs "Metric" é apenas uma propriedade de cada linha da tabela de pesquisa. Por exemplo:

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,
  ...
);

Ou, se houver necessidade de combinações de Unidades que cruzam diferentes sistemas de medição, eu usaria tabelas separadas -- uma para cada tipo de medição: "WeightUnits" e "HeightUnits". Eu não misturaria unidades para alturas e pesos na mesma tabela (ou seja, "kg" e "cm" em linhas diferentes). Por exemplo:

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"
);

Neste modelo, cada tipo de medição em qualquer tabela possui seu próprio FK pessoal para sua tabela de pesquisa de unidades de medição.

Vendo como esta questão é em relação ao design, as respostas provavelmente serão bastante opinativas...

Aqui está a minha opinião sobre como ele deve ser projetado. ;)

Tabela para armazenar unidades de medida

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

Sua mesa pessoal...

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
)

E então uma tabela de conversão

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
)

Se uma unidade de medida não tiver uma entrada na tabela de conversão de medida para outro tipo específico de unidade, não haverá conversão direta disponível. (Por exemplo, cm -> polegadas funcionaria, mas cm -> horas não...) Deve ser fácil exibir suas medidas em diferentes unidades.

Sua unidade de medida pode ser qualquer coisa que você quiser (distância/tempo/etc)... mas você pode querer adicionar um tipo de medida... não tenho certeza se me preocuparia com isso - depende do caso de uso.

Se suas unidades de medida de altura/peso forem realmente fixas , ou seja, altura=CMs, Peso=KGs, eu não introduziria nenhuma coluna adicional (ou lógica) para especificar a unidade de medida. Em vez disso, o que eu faria é apenas alterar o nome da coluna, como

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

Dessa forma, posso remover qualquer confusão sobre a unidade de medida para as colunas Altura e Peso.

Depende do que você está projetando... um sistema OLTP normalizado teria uma tabela de medidas separada (ou algum nome semelhante) que fornece integridade referencial e otimizações de desempenho para cada unidade de medida possível.

Se você estiver fazendo análises e lidar com unidades com pouca frequência e fizer menos conversões, isso pode ser armazenado como um atributo. Isso ainda seria raro - algo como respostas a pesquisas ou um padrão da indústria como metragem quadrada para imóveis. Mas o que mais é medido e faz sentido no mercado imobiliário? planos de chão? Agora temos polegadas... e quadrados e cúbicos. Voltamos a um design normalizado.

Para altura, uma variedade de medidas são aplicáveis ​​e fazem todo o sentido em vários contextos. Provavelmente uma boa ideia usar um design como este:

dbo.PersonHeight
Height     MeasureFK
62           2

dbo.UnitsOfMeasure
MeasureID  MeasureDescription
2          Inches
3          Centimeters

Com esse design, você pode criar facilmente uma tabela de pesquisa/conversão agora:

dbo.UnitConversions
FromMeasureID    ToMeasureID    Conversion
2                 3             0.39370079