Sparar användarens längd och vikt

Det finns flera sätt... ett är att bara ha två numeriska kolumner, en för längd, en för vikt, och sedan göra omvandlingarna (om nödvändigt) vid visningstidpunkten. En annan är att skapa en "höjd"-tabell och en "vikt"-tabell, var och en med en primärnyckel som är länkad från en annan tabell. Sedan kan du lagra både engelska och metriska värden i dessa tabeller (tillsammans med annan metainformation du vill ha):

CREATE TABLE height (
    id          SERIAL PRIMARY KEY,
    english     VARCHAR,
    inches      INT,
    cm          INT,
    hands       INT  // As in, the height of a horse
);

INSERT INTO height VALUES
    (1,'4 feet',           48, 122, 12),
    (2,'4 feet, 1 inch',   49, 124, 12),
    (3,'4 feet, 2 inches', 50, 127, 12),
    (3,'4 feet, 3 inches', 51, 130, 12),
    ....

Du förstår...

Sedan kommer din användartabell att referera till höjden och vikt tabeller – och möjligen många andra dimensionstabeller – stjärntecken, civilstånd, etc.

CREATE TABLE users (
    uid         SERIAL PRIMARY KEY,
    height      INT REFERENCES height(id),
    weight      INT references weight(id),
    sign        INT references sign(id),
    ...
);

För att sedan göra en sökning efter användare mellan 4 och 5 fot:

SELECT *
FROM users
JOIN height ON users.height = height.id
WHERE height.inches >= 48 AND height.inches <= 60;

Flera fördelar med denna metod:

• Du behöver inte duplicera "ansträngningen" (som om det vore något verkligt arbete) för att göra konverteringen på displayen – välj bara det format du vill visa!
• Det gör det superenkelt att fylla i rullgardinsrutor i en HTML-val--bara SELECT english FROM height ORDER BY inches , till exempel.
• Det gör din logik för olika dimensioner – inklusive icke-numeriska sådana (som astrologiska tecken) uppenbarligen lika – du har inte specialfallskod överallt för varje datatyp.
• Den skalar riktigt bra
• Det gör det enkelt att lägga till nya representationer av dina data (till exempel för att lägga till kolumnen "händer" i höjdtabellen)