Jag förmodar att du har en användartabell med med namn och dylikt och där skulle jag lagra födelsedatum i en kolumn med typen date. Jag skulle aldrig lagra datum uppdelat enligt ditt förslag.
Frågan#1
Hejsan, nu har jag en liten stilla undran igen :)
Jag har skapat en tabell som skall ta emot användardata.
För att den skall kunna vara flexibel och ta emot olika typer av data, utan en massa fält, så har jag designat den såhär:
id (unikt id, primärnyckel)
uid (användarens id)
fldKey (en ett ord lång beskrivning av vad som finns i fldValue)
fldValue (ett värde)
Detta kan ju då tillexempel bli:
1 : 1 : shoesize : 43
2 : 1 : eyecolor : green
3 : 2 : shoesize : 37
4 : 2 : eyecolor : brown
etc.
Och nu tänkte jag då på liknande sätt lägga in födelsedata, enligt principen
idX : uidX : year : 1981
idX : uidX : month : 09
idX : uidX : day : 20
(detta så att man kan låta bli att fylla i månad och eller dag) Eller år... aja men ni förstår principen.
Nu till frågan, är det smartare att slänga in dessa noll till tre rader per användare i den stora userdata tabellen, eller bättre att skapa en userBday tabell som bara innehåller denna data.
För å ena sidan blir det ju ganska många rader mer i den stora tabellen om man skall lägga datan där, men om man skapar en till tabell så måste manju antingen hämta den datan tillsammans med en query till den stora tabellen och joina ihop det å så eller skicka det som en egen fråga.
Så... vilket av följande sätt stjäl minst processorkraft? Eller hur man skall säga.
:)
Alla tankar och funderingar välkomna.
Tack på förhand.
MVH Patrik
