Det här är ju ett problem med relationsdatabaser, att jobba med träd strukturer. Jag har inte implementerat det själv men gillar lösningen här http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back . Naive trees på slide 49, det kommer en lösning som dom kallar "closure table" som ser ut att verka vettig.
Frågan#1
Hallå!
Jag har just nu 5 olika tabeller med olika kategorier som jag hämtar in med 5 sql-satser. Jag tänker att detta borde kunna göras i en tabell och en enda fråga. Vad tror ni?
Det är två tabell-typer för de fem kategorisorterna (3 har den första och 2 den andra) och de ser ut såhär:
ID - PID - TITEL - BG_COLOR - FG_COLOR - ORDER
resp.
ID - PID - TITEL - ABBR_TITEL - ORDER
ID är auto_increment
PID tänkte jag ska vara NULL om kategorierna ska nås i alla projekt eller en kommaseparerad sträng/serialized array med projekt-id:n om de bara ska nås från vissa projekt (behövs verkligen en extra tabell för detta annars? Jag tänker mig att man hämtar ut alla kategorier jämt ändå)
TITEL är kategorinamnet
ABBR_TITEL är en förkortning av titeln och ska bara finnas till två av kategorisorterna
BG_COLOR och FG_COLOR innehåller 6 tecken långa koder för färger, ex. 0066cc och dessa två fält gäller endast tre av kateorierna
ORDER är siffror som talar om i vilken ordning de ska listas
Just nu har jag runt 50 kategorier totalt och jag kan tänka mig att det blir runt 50-100 som max, men det beror helt på vad användaren väljer att lägga in.
Tänker jag fel när jag försöker att baka ihop olika grejer såhär eller är det smart? Vissa av fälten används bara till vissa av kategorierna som sagt så det blir lite NULL-värden. Å andra sidan känns det lockande att ha ett gemensamt inmatningssystem för allt, en sql-fråga för att hämta klabbet och slippa 70 JOINS i mina frågor.
Tack för tips!