FrilanserBob Skrevet 10. mars 2007 Del Skrevet 10. mars 2007 Driver og mekker meg et lite internt ordresystem med php/mysql. Målet er at jeg skal kunne ha styr på kunder, og legge inn ordre på dem. Men nå har jeg fått et lite ”problem”. Jeg skal prøve å forklare med noen punkter; - En ordre kan inneholde fra en til flere produkter/tjenester - En klient kan ha flere ordre pr. dag - Jeg må kunne tildele ordrenummer til orden, og da kan ikke hver linje med produkter bestilt ha eget ordrenummer. - Jeg vil at ordrenummeret skal starte på 1 000 000 Hvordan ville folket ha organisert databasen? Jeg har en klienttabell, som identifiserer klientene gjennom feltet klient_id. Likeså har jeg en produkttabell hvor produktene identifiserers gjennom produkt_id. Mitt problem er at jeg er veldig i tvil om hvordan jeg bør legge opp ordretabell(-ene) på en enklest mulig måte slik at jeg slipper å lage noen megastore spørringer og innvikla løsninger. Hvilke tabeller burde jeg legge opp for å få et bra ordresystem, og hvordan bør jeg strukturere disse med tanke på de punktene jeg skrev over? Å bruke systemer slik som joomla osv er ikke aktuelt, og dermed basta… Lenke til kommentar
blacktower Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 Klienter (en klient har mange ordre) Ordrer (en ordre har en klient og mange ordrelinjer) [inneholder id til klient] OrdreLinjer (en ordrelinje har en ordre og et produkt) [inneholder id til ordre og produkt] Produkter (et produkt har mange ordrelinjer) Lenke til kommentar
CruellaDeVille Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 (endret) ((Jeg får kjeft når jeg quoter første tråd, så glemmer jeg noe beklager jeg det)) Du skal ha kunde, vare, ordre? Jeg ville hatt en tabell for kunde, en for vare og en for ordre (pluss en til, men den kommer jeg tilbake til). Kunde - ordre: 1:m - en kunde kan ha mange ordre, en ordre tilhører bare en kunde vare-ordre: n:m - en ordre kan inneholde mange varer, en vare kan inngå i mange ordre. Den fjerde tabellen (feks ordre_linje): En standardløsningn på dette er å lage en relasjon av mange-til-mangeforbindelsen mellom vare og ordre, med feks et ordrenummer og et varenummer som primærnøkkel og fremmednøkkel. Da vil tabellene se noe slikt ut kundeid |kundenavn |....| 1 |Cenit |....| 2 |UiB |....| Vare id |navn |pris |lagerbeh | 1 |Såpe |23.90 |500 | 2 |melk |19.87 |100 | Ordre id | dato |kundenr| 1 |23.12.2007 |1 | 2 |24.05.2001 |1 | 3 |24.05.2001 |1 | 4 |24.05.2001 |2 | ordre_linje ordre | vare |antall | 1 |2 |20 | 1 |1 |2 | 2 |1 |30 | 2 |2 |200 | 4 |1 |20 | 5 |1 |20 | Når du skal hente ut faktura til Cenit henter du ut kundenr, ordrenr, dato, varenavn, antall, pris fra kunde, vare, ordre, ordre_linje hvor kundenr i kundetabell er lik kundenr i ordre og ordrenummer i ordretabell er lik ordrenummer i ordrelinje-tabellen og varenummer i ordrelinje-tabellen er lik varenummer i varetabellen. Tror det blir noe slikt som dette, med forbehold om feil, siden jeg ikke får testet select kunde.kundenavn, ordre.id, ordre.dato, vare.navn, ordrelinje.antall, vare.pris from kunde kunde, ordre ordre, vare vare,ordre_linje ordrelinje where kunde.id = ordre.kundenr and ordre.id = ordrelinje.ordre and ordrelinje.vare = vare.id and kunde.id = 1 #variant to, jeg er usikker på join syntax, men tror det er slik select kunde.kundenavn, ordre.id, ordre.dato, vare.navn, ordrelinje.antall, vare.pris from kunde kunde, ordre ordre, vare vare,ordre_linje ordrelinje inner join (kunde.id= ordre.kundenr) inner join (ordre.id=ordrelinje.ordre) inner join (ordrelinje.vare = vare.id) and kunde.id = 1 Endret 11. mars 2007 av CruellaDeVille Lenke til kommentar
FrilanserBob Skrevet 11. mars 2007 Forfatter Del Skrevet 11. mars 2007 (endret) ... Hvordan får jeg lagt inn ordre, med tanke på at jeg må ha et ordrenummer ganske tidlig slik at jeg får lagt det over til de andre tabellene? Ikke quote hele sulamitten -blacktower Endret 11. mars 2007 av blacktower Lenke til kommentar
roac Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 Jeg vil bare få minne om en felle det er lett å gå i her: Hvis fakturanummer (for jeg regner med at du skal ta deg betalt også) skal være det samme som ordrenummer så kan du ikke bruke auto_increment, grunnet krav om løpende nummerserie. Lenke til kommentar
FrilanserBob Skrevet 11. mars 2007 Forfatter Del Skrevet 11. mars 2007 Jeg vil bare få minne om en felle det er lett å gå i her: Hvis fakturanummer (for jeg regner med at du skal ta deg betalt også) skal være det samme som ordrenummer så kan du ikke bruke auto_increment, grunnet krav om løpende nummerserie. 8126743[/snapback] den ligger inne som en tellerverdi som gir en løpende nummerserie Lenke til kommentar
FrilanserBob Skrevet 11. mars 2007 Forfatter Del Skrevet 11. mars 2007 Det jeg egentlig lurer på er hvordan jeg skal få lagt inn ordrene, slik at jeg får med meg et nytt ordrenummer, og at jeg får med det videre til de andre tabellene Lenke til kommentar
blacktower Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 ...? maybach_dev=# INSERT INTO orders (...) VALUES (...); INSERT 0 1 maybach_dev=# SELECT id FROM orders ORDER BY id DESC LIMIT 1; id --------- 1000005 (1 row) Lenke til kommentar
CruellaDeVille Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 Det jeg egentlig lurer på er hvordan jeg skal få lagt inn ordrene, slik at jeg får med meg et nytt ordrenummer, og at jeg får med det videre til de andre tabellene 8127238[/snapback] Jeg skjønner ikke helt hva du spør om. Hvordan insert-setningen skal være? Hvordan interface må være? Hvis det er det første kan du bruke det han ovenfor skrev. For å finne ordrenummer setter du først inn verdier i ordretabellen og deretter bruker du mysql_insert_id() for å finne ordrenummeret for å sette inn i ordre_linje. Lenke til kommentar
roac Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 den ligger inne som en tellerverdi som gir en løpende nummerserie 8127179[/snapback] Les det jeg skrev. Hvis du bruker auto_increment (av noen kalt tellerverdi) så er denne IKKE garantert å gi løpende nummerserie, men et ledig nummer høyere enn det siste innsatte. Ved rollback av en transaksjon VIL du få hull i nummerserien, og det er ikke revisor glad for Lenke til kommentar
abrj Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 (endret) den ligger inne som en tellerverdi som gir en løpende nummerserie 8127179[/snapback] Les det jeg skrev. Hvis du bruker auto_increment (av noen kalt tellerverdi) så er denne IKKE garantert å gi løpende nummerserie, men et ledig nummer høyere enn det siste innsatte. Ved rollback av en transaksjon VIL du få hull i nummerserien, og det er ikke revisor glad for 8132341[/snapback] Hva mener du med rollback av transaksjon? Hvordan kan han løse dette da? Er det noen alternativer til auto_increment? Endret 11. mars 2007 av abrj Lenke til kommentar
roac Skrevet 11. mars 2007 Del Skrevet 11. mars 2007 Hva mener du med rollback av transaksjon? Hvordan kan han løse dette da? Er det noen alternativer til auto_increment? 8132922[/snapback] Alle operasjoner i en database gjøres i en transaksjon, enten eksplisitt (ved at du definerer den selv) eller implisitt (ved at en kommando oppretter den for deg). En transaksjon er en gruppe med en eller flere kommandoer som har den egenskap at enten utføres alt eller ingen ting. Transaksjoner er essensielt for denne typen løsninger som beskrives her, og jeg vil på det sterkeste anbefale alle som jobber med denne typen oppgaver å sette seg inn i transaksjonshåndtering. En transaksjon kan enten commites (hva blir et godt norsk ord her, bekreftes? iverksettes?) eller rulles tilbake. I førstnevnte tilfelle skrives alle dataene til disk, i sistnevnte skrives de ikkke til disk. Rollback (tilbakerulling) kan skje enten på grunn av en oppdatering som feiler, eller f eks i forbindelse med restart og/eller kræsj av databaseserveren. Lenke til kommentar
FrilanserBob Skrevet 12. mars 2007 Forfatter Del Skrevet 12. mars 2007 Roac: det vil tas backup på en timelig basis, og det vil ikke være så stor hyppighet av ordre inn. Hvis noe ryker og man kjører tilbake backupen vil jo auto_increment fortsette der den slapp på siste registrerte ordre. Lenke til kommentar
roac Skrevet 12. mars 2007 Del Skrevet 12. mars 2007 Roac: det vil tas backup på en timelig basis, og det vil ikke være så stor hyppighet av ordre inn. Hvis noe ryker og man kjører tilbake backupen vil jo auto_increment fortsette der den slapp på siste registrerte ordre. 8134024[/snapback] Ok, dårlig design fordi vi i utgangspunktet ikke ser at vi trenger godt design. Den er grei, men ikke kom til meg den dagen du evt får trøbbel med revisor. Jeg kom med eksempler på tilfeller hvor transaksjoner rulles tilbake, det er andre også. Lenke til kommentar
FrilanserBob Skrevet 12. mars 2007 Forfatter Del Skrevet 12. mars 2007 Fortell meg hva alternativet er da! Hvordan kan jeg få fortløpende nummer, som ikke blir ødelagt av det du kaller en rollback? Du gauler om at auto_increment ikke er bra, men hva er alternativet? Lenke til kommentar
roac Skrevet 12. mars 2007 Del Skrevet 12. mars 2007 (endret) Fortell meg hva alternativet er da! Hvordan kan jeg få fortløpende nummer, som ikke blir ødelagt av det du kaller en rollback? Du gauler om at auto_increment ikke er bra, men hva er alternativet? 8134360[/snapback] Du har en egen tabell som du henter verdiene ut i fra, og bruker en eksplisitt transaksjon for hver nye ordre. Mao: Start en ny transaksjon, hent ut høyeste verdi fra tabellen med eksklusiv låsing, sett inn ny ordre med verdi med id en høyre, sett inn denne iden i tabellen med tellerverdiene dine, commit transaksjonen. Og bare så det er sagt, det er ikke snakk om noe jeg kaller rollback, det er elementær databasekunnskap som du burde ha kontroll på lenge før du begir det ut på et slikt prosjekt. Endret 12. mars 2007 av roac Lenke til kommentar
CruellaDeVille Skrevet 12. mars 2007 Del Skrevet 12. mars 2007 (endret) Det du må gjøre da er å legge inn insert (og oppdatering/delete) i en transaksjon. Når hele spørringen går igjennom kjører du en commit eventuelt en rollback. Fant denne: http://www.devarticles.com/c/a/MySQL/Using...QL-4.0-and-PHP/ Kanskje du kan bruke noe derfra. Hvis du har mysql 5 kan du se på denne siden: http://www.devshed.com/c/a/MySQL/Using-Tra...MySQL-Part-1/4/ Endret 12. mars 2007 av CruellaDeVille Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå