Trenger tips til DB-design

[MikkelRev]

Jeg holder på med en Taekwon-Do-database. I Taekwon-Do har man noe som heter mønster (aka kata, poomsae, forms, patterns, hyong, tul), som er et sett av bevegelser. Et mønster består av feks 30 bevegelser. Hver bevegelse er en kampteknikk, feks et middels punch i gåstilling utført i fast motion.

 

Jeg trenger tabell for alle bevegelsene for hvert mønster.

Et mønster består av mange bevegelser.

En bevegelse består av en stance, en height, en line, en facing og en motion.

 

 

Jeg har disse tabellene:

* tblMovement (pattern_id int, name varchar, stance int, height int, line int, facing int, motion int, info text)

Dette er bevegelsene med fremmednøkler til hver av egenskapene. int'ene er fremmednøkler til Technique.id. Jeg har valgt å bruke fremmednøkler istedetfor å hardkode (varchar) navnene på stance, height, line, facing og motion.

 

 

* tblTechnique (id int, name_english varchar, name_korean varchar, info text, type int)

Dette er en slags ordliste. Type angir hvilken type teknikk/kategori det er snakk om. 1 for stance, 2 for height, 3 for line osv.

Så eksempelposter: 11, low, najunde, blabla, 2 / 12, middle, kaunde, blabla, 2 / 13, high, nopunde, blabla, 2 / 14, center line, bla, blabla, 3 / 15, shoulder liner, bla, bla bla, 3 / osv

 

 

Slik jeg har satt det opp nå, hvordan kan jeg kjøren en spørring for å få en bevegelse sin name, stance, height, line osv ?

 

Til nå har jeg måttet kjøre en egen spørring med hver sin JOIN for hver av fremmednøklene. Det er fordi når jeg join'er tblTechnique, så vil name kun kunne inneholde en verdi om gangen.

 

Et alternativ hadde vært å dele opp tblTechnique i fullt av småtabeller, så jeg får tblStance, tblHeight, tblLine osv. Ikke helt idéellt, ettersom det fort blir veldig mange småtabeller hver bestående av gjerne bare 2/3 poster, og dessuten ønsker jeg å kunne kjøre samme behandling i kodebiten på alle sammen.

 

Så tips?

Endret 22. desember 2010 av MikkelRev

[slacky]

Tror du må spesifisere deg mer på den "utvikler" fronten. Hva skal du ha? Hva har dette med DB-design å gjøre? Er du ute etter å lagre "masse" info i vært felt? Random eks: "user_friends" inneholder alle brukerens venner i bare et felt.

 

Eller hva er det du tenker på? Det må tyding til for å forstå en brøkdel, da du mikser inn et ukjent felt som flere av oss ikke har forståelse for. Vi er nerder, ikke slosskjemper slash nerd

 

Om det jeg spurte om er korrekt (lagre mye infor pr felt, plukke ut bare det du øsnker osv slik bla bla bla... Da annbefaler jeg (php) explode

 

$moods  = "wild.horny.bored.happy.sleepy.sad";
$split = explode(".", $moods);
echo $split[0]; // wild
echo $split[1]; // horny
echo $split[2]; // bored

 

Men, jeg vet egentlig ikke hva du ønsker ^^ I hope it was any help !

 

God jul (=

Endret 22. desember 2010 av tROOP4H

[MikkelRev]

Jeg vil ikke ha mange verdier i samme celle, det er dårlig databasedesign!

 

 

Jeg kan ta et annet eksempel på det så det kanskje blir lettere å forstå.

Istedetfor bevegelse, har jeg en tblLåt.

Istedetfor teknikk (glosetabellen), har jeg en tblPerson.

 

Tenk deg at det finnes forskjellige typer personer, en type person er låtskrivere og bare låtskrivere, en type person er vokalister, en er gitarist osv.

 

tblLåt (int id, låtskriver id, vokal id, gitar id, tromme id, produsent id)

 

tblPerson (int id, navn, type int, info text)

 

tblPerson.type er et flagg som sier hvilken type person han er, om han er låtskriver, vokalist, produsent, etc. I praksis kommer det nok litt flere typer personer.

 

 

Om jeg nå vil ha all info om en låt med en spørring, hvordan skriver jeg den spørringen?

[slacky]

Hehe, vel dette må jeg si ble litt vanskelig å tyde.. Eksempler ser jeg mye av her, og sikkert veldig gode, men det betyr at jeg må tyde dem, noe jeg har vanskligheter for, er for mye stress for tiden, bekalger :|

 

Kan ikke se problemstillingen din, det er vel alt.. Jeg sliter også med å fårstå denne setningen Til nå har jeg måttet kjøre en egen spørring med hver sin JOIN for hver av fremmednøklene. Det er fordi når jeg join'er tblTechnique, så vil name kun kunne inneholde en verdi om gangen... Men tyder jeg det rett så vet jeg KANSJE svaret ^^

 

 

Problemstillingen din er altså at du må kjøre multiple sql spørringer, for å hente ut info f. eks i forhold til et type spark; height, stance el. lignenede..?

 

Om så.. Da er vel kansje løsningen LEFT JOIN?

 

Må kommentere at det er da ikke dårlig dbdesign å holde på flere verdier i samme celle. det effektiviserer bruken av tabeller vil jeg si ^^ Men, er vel 100% smak og behag, da det ikke fører til noen negative sider

Endret 22. desember 2010 av tROOP4H

[MikkelRev]

Kan ikke se problemstillingen din, det er vel alt.. Jeg sliter også med å fårstå denne setningen Til nå har jeg måttet kjøre en egen spørring med hver sin JOIN for hver av fremmednøklene. Det er fordi når jeg join'er tblTechnique, så vil name kun kunne inneholde en verdi om gangen... Men tyder jeg det rett så vet jeg KANSJE svaret ^^

Om jeg vil ha ut all info om en bevegelse nå blir det slik:

 

//Hent ut generell info

SELECT name, tech, info

FROM movement

WHERE id=$id

 

//Også hent ut stance'en

SELECT name_en AS stance

FROM movement

LEFT JOIN tech ON tech.id=movement.stance

WHERE id=$id

 

//Også hent ut height'en

SELECT name_en AS height

FROM movement

LEFT JOIN tech ON tech.id=movement.height

WHERE id=$id

 

//Også hent ut line'en

SELECT name_en AS line

FROM movement

LEFT JOIN tech ON tech.id=movement.line

WHERE id=$id

 

//også en egen spørring for facing, en for motion og en for andre ting.

 

Skjønner? Tungvint, istedetfor å kun ha en spørring.

 

Må kommentere at det er da ikke dårlig dbdesign å holde på flere verdier i samme celle. det effektiviserer bruken av tabeller vil jeg si ^^ Men, er vel 100% smak og behag, da det ikke fører til noen negative sider

Litt avsporing. Tror ikke jeg har bruk for å ha flere verdier i samme celle. Dessuten bryter det jo i teorien med første normalform.

[quantum]

Se på de to første spørringene dine. Hvilke felt henter du ut i den første som du ikke like godt kunne hentet i den andre? Ingen? Riktig, og dermed er halve jobben gjort

 

edit: nærmere bestemt

 

select m.name, m.tech, m.info,

t1.name_en as stance, t2.name_en as height, t3.name_en as line

from movement m

left join tech t1 on t1.id = m.stance

left join tech t2 on t2.id = m.height

left join tech t3 on t3.id = m.line

where m.pattern_id = $id

 

... men her har jeg antatt at det er movement.patternt_id

du tenker deg at du bruker i alle where-claus'ene. hvis du egentlig mener tech.id i alle spørringene unntatt den første, må du legge dette inn i join-betingelsene:

 

join blalba on t#.id = m.stance and t#.id = $id.

Endret 22. desember 2010 av quantum

[slacky]

//Denne koden fungerer kansje ikke HELT i praksis, men er en kjapp veileder for det du forsøker.
$result = mysql_query(
"SELECT tn.name_en AS line, tc.name_en AS stance, tm.name_en AS height, name, tech, info FROM movement tx
LEFT JOIN tech tn ON tn.id=tx.line
LEFT JOIN tech tc ON tc.id=tx.stance
LEFT JOIN tech tm ON tm.id=tx.height
WHERE tx.id=$id"
);

//******** Noe gamle saker jeg fant frem som et eksempel (som fungerer) ;p ********//

$result = dbquery(
	"SELECT tn.*, tc.*, tm.*, user_id, user_name FROM prfx_news tn
	LEFT JOIN prfx_users tu ON tn.news_name=tu.user_id
	LEFT JOIN prfx_news_imgs tc ON tn.news_img=tc.news_img_id
	LEFT JOIN prfx_news_cats tm ON tn.news_cat=tm.news_cat_id
	ORDER BY news_sticky DESC, news_datestamp DESC LIMIT 14"
);

 

/EDIT, mye feil her... Men, du ser hvor jeg går, og kan utvikle selv? ^^

Kan dette stemme, må regne med en feil her, eller 2... Som jeg sier så er jeg litt bortevekk ^^

Er ikke sikker på om det lar seg gjøre akkurat slik, men tror det er noe i det

Endret 22. desember 2010 av tROOP4H

[MikkelRev]

Tok ikke den helt, quantum.

 

Jeg kunne merget de to første spørringene ja, den generelle og den for stance:

 

SELECT name, tech, info, name_en AS stance

FROM movement

LEFT JOIN tech ON tech.id=movement.stance

WHERE id=$id

 

Men må likevel kjøre en separat spørring for line, height, facing, motion...

[quantum]

Men må likevel kjøre en separat spørring for line, height, facing, motion...

se edit'en i forrige innlegg.

[slacky]

quantum viser til det samme som meg, og er nok akkurat det du er ute etter, det gjør susen, med bare EN spørring ^^

Tror du skjønner hva vi viser til, og at dette gjør alt noen hakk lettere

Endret 22. desember 2010 av tROOP4H

[MikkelRev]

Takker, det hjalp!

[MikkelRev]

Trenger mer hjelp til å tenke klart.

 

Jeg har disse tabellene (tar kun med relevante felt):

 

tblPattern(pattern_id)

tblMove(move_no, pid)

tblModel(model_id,fname,lname)

tblPic(pic_id,move_no,pattern_id,model_id)

tblPatternmodel(pattern_id,model_id)

 

Jeg er usikker på om jeg trenger tblPatternmodel i det hele tatt, og egentlig både på hvilke fremmednøkler jeg trenger og hvordan jeg skal skrive spørringen. Jeg har tegnet tabellene ned på papir og ser at det går an å koble den sammen på 100 forskjellige måter, så ting går helt i surr for meg

 

Det er vanskelig å forklare hvordan dette virker, men skal prøve så godt jeg kan om det trengs.

 

Jeg søker etter en spørring der jeg får opp følgende (eksempel):

 

MODEL_ID -- FNAME -- LNAME -- PIC_ID

5 -- MIKKEL -- REV -- 17

 

Dersom det ikke er registrert et bilde, vil jeg istedetfor et tomt resultat ha:

5 -- MIKKEL -- REV -- NULL

 

 

 

Her er en (av flere) spørringer jeg har prøvd:

 

SELECT patternmodel.model_id, fname, lname, pic.id
FROM patternmodel
LEFT JOIN model ON model.id = patternmodel.model_id
LEFT JOIN pic ON pic.model_id = model.id
WHERE pattern_id = 20
AND patternmodel.model_id =5
AND move_no=4

Denne spørringen funker greit og gir:

5 -- MIKKEL -- REV -- 17

 

men om jeg derimot i spørringen endrer move_no fra 4 til move_no=5, får jeg et tomt resultat istedetfor å bare få NULL på pic_id.

tblPic(pic_id,move_no,pattern_id,model_id) har nemlig posten (17,4,20,5), men det er ingen med oppføring (nn,5,20,5)