Jeg bruger udelukkende at hente den anden vej. Hvilke ting er gule, o.s.v. Ovenstående skal jeg kun bruge for at kunne se i hvilke kategorier eksempelvis bananer hører under. Derfor.
Så har du gul = id = 4 Så tager du alle fra tabellen: frugt-egenskaber WHERE egenskab_id = 4 Og så en inner join med frugt, så har du alle ting som er gule. f.eks.
Der vil jeg give jakobdo ret. Du har brug for at lave dit design om, der er ikke sæligt godt at have alt for mange tomme felter i en tabel. jakobdo's forsalg giver dig mulighed for netop at søge begge vej på forskellige ting, det giver dig samtidig mulighed for nemt at oprette nye egenskaber uden at skulle ændre i opbygningen af din tabel. Du får heller ingen tomme felter. Det er også nemt for dig at slette ting igen, hvis dette skulle blive nødvendigt.
Mit udgangspunkt er at jeg lister ud fra det jakobdo kalder egenskaber, altså find alle ting der hører under eksempelvis frugt. Dette er det kald der bliver brugt i 99% af tilfældende hvor man skal kalde fra databasen. Der har jeg set det nemmest, blot at løbe en kolonne igennem, ud fra feltnavn:
while($row = mysql_fetch_array($result)) { // forenklet kode vist if ( $row[$grp] <> "" ) { echo '<p>' . $row[$grp] . '</p>'; }}
Simpelt og enkelt kald, frem for at skulle hente en række ( $row[$grp] ) og løbe dennes array igennem, sortere alfabetisk o.s.v.
Da det er en forholdsvis lille tabel (lige nu ca. 250 felter og 32 rækker), som (aldrig) kommer til at vokse i størrelse men blot en sjælden gang imellem bliver ændret, har jeg valgt løsningen jeg bruger nu. Jeg havde overvejet jakobdo's løsning 20/05-2007 17:03:30, men besluttede mig for at det var overkill.
Det skal ikke være nogen hemmelighed at det er en slags fagbog det drejer sig om. Kolonneoverskrifterne, det phpMyAdmin på dansk kalder feltnavne er: Advokater, Akupunktur, Anlægsgartnere, Antenner, Antikviteter o.s.v. ( ca. 250 stk. ) På forsiden over kategorier, lister jeg blot feltnavnene med:
while ($i < mysql_num_fields($result)) { // forenklet kode vist $meta = mysql_fetch_field($result, $i); $kat = $meta->name; echo '<p>' . $kat . '</p>'; }
Igen et simpelt og hurtigt kald. Og hvis tømrer Jensen henvender sig for at blive tilføjet kategorien Snedkere er det let at søge efter første ledige celle i kolonnen (feltnavnet) Snedkere, og indsætte hans firmanavn der. Men for at jeg på min administrationsside kan se hvilke kategorier tømrer Jensen står i, har jeg brug for det script jeg oprindelig forespurgte. For mig gør det ikke noget at det tager et sekund ekstra i ventetid, men jeg fik samtidig den idé at det også kunne være smart på tømrer Jensens side at vise hvilke kategorier hans firma står under.
Jeg har ikke nogen tomme rækker eller felter i den pågældende tabel.
Lige et par ting. At joine to tabeller er ikke noget indviklet kald til mysql, faktisk noget mysql er skabt til. Og præsic som jakobdo skiver, så kaldes det normalisering, når man opbygger sin database med færst muligt tekst og flest henvisniger. Din struktur på tabellen bliver hurtigt uoverskuelig og for andre vil der blive meget svært at finde rundt i, bare se på hvor lidt vi forstod.
Det er helt forkert hvis du ikke mener at du ikke har tomme felter, det du viste var da fuld af tomme felter!
Netop til dit problem vil en normalisering af dit tabelstrukur hjælpe på dit problem. Det har intet med hvor lang tid det ville tage mysql at lave en forespørgsel, men hvor kombiseret din php kode vil være og hvor meget unødigt data du vil hente fra din database. Tænk på hvis tømrer Jensen nu ændre egenskab eller han ændre adresse, så skal du ikke bare ændre 1 sted, men alle de steder hvor du har lagt tømrer Jensen. Og hvis du staver forkert ?? Det vil for dig selv blive meget lettere i fremtiden, hvis du fra starten lærer at normalisere din tabelstruktur.
En tabel med 250 felter må da også være rigtig uoverskuelig at håndtere.
Jeg forstår ikke lige den med tomme felter. Selvfølgelig er der masser af tomme felter. Med mindre I vil have jeg skal skrive "-1" eller lignende i alle disse.
Alle virksomhedsoplysninger ligger også i en anden tabel, ud fra et ID.
Hvis jeg skal følge jakobdo's eksempel, skal jeg oprette 250 tabeller. Det lyder voldsomt, og uoverskueligt.
En væsenlig regel i ordenlig database design er at data, som IKKE har noget med hinanden at gøre, ikke må stå på samme række. Hvis dette også skal gælde for din tabel, så vil du for hver række, have 249 tomme felter, men mindre der er nogen som har 250 egenskaber ? Hvilket felt i din tabel er din Primary Key ?? Hvordan vil du gemme adresse for de personer/firmaer som ligger i din tabel ??
Nej du skal netop ikke oprette 250 tabeller med kun 3 tabeller. Den ene tabel har du allerede, det er din adressetabel, hvor hvert firma har en unik id.
Den anden er en tabel med dine egenskaber. Her er et to felter, et unikt id felt og et navnefelt på din egenskab
Den trejde tabel kobler de to tabeller sammen. Således at der er 3 felter, et unik id felt, et felt til id for en egenskab og et felt til firma id. Firmaid og egenskabsid kan sagtens optræde flere gange i denne tabel.
Når du så vil liste alle egenskaber, lister du bare anden tabel. Når du vil liste alle dine firmaer, lister du adressetabellen.
Når du vil vide hvilke egenskaber det bestemt firma har så søger du i den tredje tabel med det firmaid du vil undersøge, så får du nogen egenskabsid'er som du så kan hente navnene på i egenskabstabellen.
Jeg kan godt se det fornuftige i det I foreslår. Det er heller ikke normalt jeg laver tabeller på den måde, og jg var meget i tvivl om hvordan jeg skulle lave det. Jeg lavede det hele på den måde jeg gjorde, da det var mere overskuelig at se - med benævnelse - hvilke virksomheder der hørte under hvilken kategori. Ulempen ved måden jeg har lavet det på er, at skifter en virksomhed navn, skal jeg ændre det i flere tabeller.
Ulemperne ved at ændre det til det I foreslår er:
Tabellen er for længst færdig. Siden er allerede lavet, og har kørt i 5 måneder. Google har for længst indekseret sitet.
Tak for det, jeg havde forstået ideen. I en fremtidig udgave af siden vil jeg klart overveje at lave det mere korrekt. Og næste gang jeg er i tvivl om et databasedesign, vil jeg henvende mig på E.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.