14. november 2011 - 13:39Der er
14 kommentarer og 1 løsning
Explode ids og hente fra anden database
Jeg beklager den kryptiske overskrift men viste ikke helt hvad jeg skulle kalde mit problem..
Jeg er igang med at udarbejde en aktivitetskalender, hvori der i databasen er en tabel der hedder "Aktivitetskalender" - hvor alle begivenheder bliver smidt i og loadet ind i kalenderen.. Under "Aktivitetskalender" kan man så vælge noget udstyr, som bliver defineret i en varchar med ids som fx. ku se således ud: 1,3,7
De id's linker så til en tabel der hedder "Aktivitetskalender_udstyr"..
Mit problem er så at når jeg poster alle mine kommende aktiviteter, så har jeg kun id'en på det forskellige udstyr, og der skulle jeg gerne hente navnet på det enkelte udstyr fra udstyrs tabellen..
Så skulle du måske kigge lidt nærmere på designet af din database. Et eksempel kunne være at oprette en ny tabel hvor du så gemmer dine id'er fra Udstyret og peger den på id fra Aktivitetskalender
Hvis jeg har forstået situationen korrekt, så kunne du gøre tingene nemmere ved i tabellen 'Aktivitetkalender' at droppe det felt hvor du indfører udstyrs id'erne og i stedet at indføre en tredje tabel som jeg her skal kalde 'aktivitet_udstyr' således:
Aktivitetskalender id dato beskrivelse .... 1 '2011-11-01' 'bowlingturnering' 2 '2011-11-02' 'flagstangsmaling' 3 '2011-11-03' 'træskobal'
Udstyr id navn 1 'bowlingkugle' 2 'tommestok' 3 'træsko' 4 'flagstang' 5 'pensel'
Så til bowlingsturneringen, aktivitet 1, skal du bruge 5 bowlingkugler, udstyr 5, til flagstangsmaling, aktivitet 2, skal du bruge 1 flagstang, udstyr 4, og tre pensler, udstyr 5, til træskobal, aktivitet 3, skal du bruge tolv træsko, udstyr 2, og til alle tre aktiviter skal du bruge en tommestok, udstyr 2.
Med den tabelstruktur kan du nemt udtrækkt aktiviteter med tilhørende udstyr. For eksempel, hvis du skal lave en liste over det udstyr du skal have med til til træskoballet bliver din query:
SELECT a.beskrivelse, u.navn, au.antal FROM Aktivitetskalender a JOIN Aktivitet_udstyr au ON a.id = au.aktivitet JOIN Udstyr u ON au.udstyr = u.id WHERE a.beskrivelse = 'træskobal'
En sådan query kan du kalde fra din php og du kan i php formattere og præsentere resultatet som du har brug for.
Du vil således have en tabel for hver af de tre slags data, (1) aktiviterer (hvor du nok også vil have felter for tidspunkt, lokale, ansvarlige, o.s.v.), (2) udstyr, og (3) hvordan aktiviteter og udstyr passer sammen. Derved hjælper du til at 'normalisere' dine data og bringe dem i en form hvor du kan bruge sql's egne funktioner, såsom join, og ikke skal til at explode felter og lignende.
jeg kan godt se hvad i mener, men tænker bare om det ikke er helt unødvendigt at lave den 3 tabel..? Selvfølgelig, hvis det ik kan laves anderledes..
Men jeg har jo i princippet de 2 tabeller jeg skal ha, og den 3 vil jo så blive en ren "regneregel"..
Vil os komme til at få et problem hvor jeg har en funktion, hvor man kan vælge at man fx kun vil se aktiviteter hvor "Dykkerudstyr" og "Båd" er inkluderet.. Vil jeg kunne gøre det med jeres løsning?
Kan det evt. gøres ved at finde en anden måde at gemme mine id's på end med varchar??
og som jeg ser din løsning christian kommer jeg jo stadig til at skulle "implode" id'erne.. Eftersom det er forskelligt om der er 1 stk. udstyr til den enkelte aktivitet, eller om der er 5 forskellige..
Du foretrækker at have alt udstyr for en aktiviteter som en liste i et enkelt felt i tabellen. Ja, sådan kan det naturligvis også gøres, hvis dit behov er at kunne udskrive lister over aktiviteter med tilhørende udstyr. I så fald er der vel ikke engang brug for en særskilt tabel med udstyrsnavne. Du kunne skrive udstyrsnavnene direkte i stedet for aktivitets id'er. I stedet for for eksempel
'Dykke i dybet'- 1,3,4
kunne du have
'Dykke i dybet' - 'båd', 'dykkerudstyr', 'anker'.
Så kan du skrive dine aktiviteter ud uden at skulle oversætte udstyrsnumre til udstyrsnavne ved opslag i en anden tabel. Men i så fald (hvis det er omfanget af dit behov) er det egenligt spild at anvende en relationel database såsom mysql. Så er et 'redskab' som Excel mere for hånden liggende. Der er ingen grund til at anvende en teknologi blot fordi den eksisterer.
Hvis du derimod forudser at skulle bruge dine data i videre omfang, for eksempel, som du selv er inde på, at søge efter aktiviteter der skal bruge både eller dykkerudstyr, så er databasen på sin plads. Vel at mærke hvis dataerne er bragt i en egnet struktur. Hvis du for eksempel skal finde aktivitetsnavn, dato, udstyrsnavn, og antal for alle aktiviteter der bruger udstyr med navn 'båd' eller 'dykkerudstyr' kan du med en struktur som den jeg foreslår sige:
SELECT a.aktivitetsnavn, a.dato, u.navn, au.antal FROM Aktivitetskalender a JOIN Aktivitet_udstyr au ON a.id = au.aktivitet JOIN Udstyr u ON au.udstyr = u.id WHERE u.navn = 'båd' OR u.navn = 'dykkerudstyr'.
Nu snakker vi muligvis om to forskellige ting, på den ene side strukturen i databasen, på den anden side hvad du gerne vil have skrevet ud på din php side.
Lad os antage, at du for aktivitet 'Dykke i dybet' bruger båd og dykkerudstyr. Hvis så din php kode er således:
$result = mysql_query("SELECT a.beskrivelse, u.navn FROM Aktivitetskalender a JOIN Aktivitet_udstyr au ON a.id = au.aktivitet JOIN Udstyr u ON au.udstyr = u.id WHERE a.beskrivelse = 'Dykke i dybet'");
så er det en opgave for php koden, ikke for databasen. Du kunne, med den samme mysql_query, gøre noget i retning af (ikke testet, skrevet ned hurtigt som eksempel)
$result = mysql_query("SELECT a.beskrivelse, u.navn FROM Aktivitetskalender a JOIN Aktivitet_udstyr au ON a.id = au.aktivitet JOIN Udstyr u ON au.udstyr = u.id WHERE a.beskrivelse = 'Dykke i dybet'");
Så hver gang mysql queryen kommer med en række med en ny aktivitetsbeskrivelse skiftes der til en ny linie og skrives beskrivelsen ud, ellers skrives kun udstyrets navn ud. Det skulle blive til 'Dykke i dybet - båd - dykkerudstyr'.
(Kommentar til andre eksperten medlemmer: Dette kan uden tvivl optimeres. Det jeg skønnede der var behov for først var at illustrere de forskellige opgaver databasen og php koden har og hvordan man ud fra en logisk struktur i databasen kan få udskriften formatteret efter behov.)
Det var nu ikke lige det jeg mente, men mere når jeg nu skulle poste nye aktiviteter i databasen.. Så skal der jo indsættes i aktivitetskalender med dato, beskrivelse mv.. Men ligeså skal der jo indsættes i aktivitet_udstyr at fx både udstyr_id 1, og 3 skal bruges..
Det er godt nok ikke sådan ligetil det der join funktion.. Men må jo sidde og lege lidt med det :)
Tror sku jeg fik løst post problemet med følgende:
$query_kalenderudstyr = mysql_query("SELECT u.id, u.navn, ku.id, ku.kalender_id, ku.udstyr_id FROM $Tkalender k JOIN $Tkalender_kalenderudstyr ku ON k.id = ku.kalender_id JOIN $Tkalender_udstyr u ON ku.udstyr_id = u.id WHERE ku.kalender_id = '".$row['id']."' ORDER BY u.id asc") or die(mysql_error());
Puha.. Det er da en heeeeelt ny og spændende verden i fik åbnet op for mig der med det der join... Der er da UFATTELIG mange ting jeg har lavet alt alt for besværligt førhen som jeg kunne løse med det der.. :) Det må jeg rode noget mere med...
Men hvis du lige ku hjælpe mig med det sidste spørgsmål #12, så ville jeg være glad.. Og så smid et svar :)
Når du INDSÆTTER i databasen siger du nu - du startede tråden med et spørgsmål om hvordan du skulle skrive data ud fra databasen. Det har jeg forsøgt at diskutere og har brugt en del tid på. Jeg kommer nok til at stoppe her. Jeg tillader mig at oprette dette som svar, idet jeg mener at have bidraget til en løsning på dit oprindelige spørgsmål. Jeg foreslår, at du reflekterer over ovenstående og prøver at lægge dig fast på hvordan du vil opbevare dine data og så, hvis nødvendigt at oprette et nyt spørgsmål om at loade dataerne.
Det var såmænd bare et tillægs-spørgsmål som opstod efter den nye løsning på at hive tingene ud af databasen..
Jeg må prøve mig frem med det..
Og takker mange gange for de aldeles uddybene svar - det har hjulpet mig meget til at få det til at gi mening !
Synes godt om
Ny brugerNybegynder
Din løsning...
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.