Noen kjappe spørsmål om et stort (?) prosjekt

[mikk-]

Sitter og lager en auksjonsside. Denne siden kan komme til å få ganske mange brukere (i verste fall femsifret på sikt). Har i den forbindelse noen spørsmål om databasedelen.

 

Programmerer i PHP opp mot mySQL, da dette er det eneste jeg har vært borti. Føler at jeg har sånn nogenlunde peiling på begge delene.

 

Jeg har bestemt meg for å ha to hovedtabeller: auksjoner og bud.

• Alle auksjoner har en unik ID
  
• Alle bud har angitt en auksjons-id som de linkes opp mot
  

Det kan komme til å bli ganske mange bud etter hvert.

 

Noen som har innspill på dette?

 

Jeg føler at jeg vet litt for lite om databasesystemer. Siden skal foreløpig kjøre på et ganske vanlig webhotell, med 2500 mB plass. Vil dette bli tregt som sirup etter hvert?

 

EDIT: Da jeg la fram problemet mitt kjapt i en annen tråd, fikk jeg en kommentar om at dette hørtes ut som "normaliseringens verste mareritt". Kunne noen ha forklart meg litt om normalisering og hva dette går ut på? Eventuelt hvordan jeg kan begrense "marerittet"?

Endret 5. august 2005 av Mikka

[Gilbert]

Kan besnevrende lite om databaser, men har hørt rykter om at en tabellstruktur bør være slik - dersom jeg har forstått det rett:

 

tabell auksjon

id - gjenstand - osv

 

tabell relasjon

akusjon.id - bud.id

 

tabell bud

id - bud - budgiver

[Ueland]

fjartan: Dette er MySQL, der kan vi linke opp tabeller mot hverandre i spørringen. Når jeg ble undervist i Access en gang tok læreren å sa det, men jeg tror det er en Access only sak.

 

Dvs at det er strengt tatt ikke vits å ha egne lenke tabeller.

 

Forøvrig vil nok webhotellet "kaste deg ut" av den servere og over til en annen pakke hvis det blir for stort. Men husk og at så og si alle som starter et prosjekt i dag mener at det blir heihundrene stort veldig snart, men mange gir opp alt for tidlig (ting tar tid, spesielt siden det allerede finnes en god del sider)

 

Marerittet her er nok kjøretidsutvikling vil jeg tro. Hva skjer med 100 simultane brukere, 200, osv.. Og ikke minst; hva har størrelsen på tabellene å si.

 

F.eks kan det være en ide og arkivere annonsene i en annen tabell istedetfor å bare markere de som slettet for å ha minst mulig "ræl" i hovedtabellen.

[mikk-]

Det er strengt tatt ikke min side, så om den får mange brukere eller ikke spiller ikke så stor rolle. Jeg må lage en side som kanskje en gang får mange brukere uansett. Dette gjelder også webhotellet.

 

Hvis det ikke høres ut som en suicidal strategi, tror jeg jeg går for denne. Så får jeg heller ta på meg å skrive om hvis det går rett til pokker. Skal også forsøke å legge antall querys på et minimum.

[Steinmann]

Du må ikke tenkte exel ark når du skal ha databaser

La med et forslag jeg smakka sammen i visio nedenfor.

Det viser hvertfall relasjonene.

 

Når du skal ha en såpass stor database er det viktig å få den normalisert,

da tar den mye mindre plass, og blir mye lettere å vedlikeholde

Databasen din ville vært nært umulig å endre noe i

 

EDIT: Ueland: De eneste gangene man må ha en tabell "for" relasjonen, er når man får en mange til mange relasjon som ikke lar seg gjøre. Da setter man opp en tabell imellom

Endret 6. august 2005 av orsus

[mikk-]

Tusen takk, alle sammen! Om jeg bare hadde skjønt litt mer, hadde dette vært maks Jeg tror ikke jeg har bruk for å ha en egen tabell for hver gjenstand. Spesifikasjoner ligger i stedet i auksjonstabellen.

 

Utenom det, er det stort sett det samme som jeg hadde tenkt meg, hvis jeg forstår deg riktig.

 

Du nevner normalisering, og det er et ganske ukjent begrep for meg. Jeg søkte litt i google, og fant ut at det dreier seg om å ikke repetere data. Jeg kan ikke forstå annet enn at dette allerede er gjort? Hvert bud refererer bare, som i eksempelet ditt, til "aID", "uID", tid og beløp. Har jeg misforstått noe? Eller har jeg forklart meg for dårlig?

[nomore]

vel, for å si det slik, en gjenstand er en gjenstand og ikke en auksjon.

en auksjon kan ha flere gjenstander, og omvendt.

 

hva om auksjonen ble avsluttet eller stoppet, og brukeren som la den

ut ønsker å begynne på nytt, med alle, eller bare noen av gjenstandene?

da må brukeren skrive inn gjenstandene på nytt på ny auksjon, og poff så

har du gjentagende data.

 

vet ikke om det ble enklere å forstå av det eg skrev, men når man skal "designe"

databaser er dette VELDIG viktig, om ikke kritisk. en dårlig satt opp database

gir deg problemer fra dag 1, og vil kjapt vise seg som ueffektiv.

 

eg har selv en større database som brukes på jobb, og pga noe dårlig

design til å begynne med har eg innimellom brukt et par timer ekstra

bare på små modifikasjoner. noe eg hadde sluppet ellers.

 

men det er også vanskelig å tenke på alt når du begynner. derfor er normalisering veldig, veldig viktig. en perfekt strukturert database kan du legge til ting

i det uendelige uten at opprinnelig struktur og data endres.

 

men lykke til

[mikk-]

Akkurat Nå har det seg slik at det er bare firmaet som legger ut auksjoner, og en auksjon vil aldri ha flere gjenstander. Ser derfor for meg at et slikt "design" kun vil skape flere requests (og det vil vi vel ikke?)..

 

Angående indeksering, som er et tema som jeg har svært lite erfaring med: Vil det lønne seg å indeksere for eksempel Auksjons-ID i bud-tabellen?

 

Jeg har også tenkt på å lagre antall bud som har kommet inn i auksjons-tabellen. Dette for å slippe å lete unødig i bud-tabellen (noe som i tilfelle måtte blitt gjort ca 40 ganger for hver sidelasting av forsiden).

[nomore]

Akkurat  Nå har det seg slik at det er bare firmaet som legger ut auksjoner, og en auksjon vil aldri ha flere gjenstander. Ser derfor for meg at et slikt "design" kun vil skape flere requests (og det vil vi vel ikke?)..

det kommer an på spørringen din. spørringen kan kombinere disse to som

en query. og poenget mitt var om du ønsket å endre dette senere, da er du jo

låst. om du begynner slik eg sier i dag, slipper du masse ekstraarbeid senere.

og dersom du bruker spørringer rett, er det funksjonsmessig likegyldig i dag.

så hvorfor ikke?

 

Jeg har også tenkt på å lagre antall bud som har kommet inn i auksjons-tabellen. Dette for å slippe å lete unødig i bud-tabellen (noe som i tilfelle måtte blitt gjort ca 40 ganger for hver sidelasting av forsiden).

dette blir feil, da antall bud kjapt kan finnes ved en spørring. da har du dobbeltlagring. og ikke minst, hva om du senere legger til at et bud kan trekkes

tilbake? da må du jo hvirkelig lage en tung og avansert query...

[mikk-]

Så det er altså bedre å heller kjøre et query som "SELECT COUNT(*) FROM bud WHERE auksjonsid=102" for hver auksjon enn å lagre dette i selve auksjonen?

[nomore]

vel, eg mener det.

 

men for å ikke være for skråsikker og ta feil, rota eg sammen et script

som kjører forskjellige querys og tar tiden på de enkelte.

 

resultat:

 

dette er en tabell med ca 350-400 rader i.

 

den øverste tiden er total tid. den nederste er for hver enkel spørring.

Endret 6. august 2005 av nomore

[nomore]

som du kan se her er test nr 2 slik eg ville ha gjort det, og test nr 5 eller 6 slik

du ville gjort det.

 

og det viser jo her at slik du vil gjøre det er kjappest, men eg tror dette

er pga liten tabell(lite data). men ikke sikker.

 

men om det står imellom test 7 og en annen er valget litt avhengig

om du skal bruke dataene også. trenger du dataene er test 7 best,

dersom du bare skal ha tellinga er alle de andre å foretrekke.

litt referanse.

[mikk-]

Hjertlig, nomore!

 

Ser jo ut som den totale tida var mye bedre (nesten 4 ganger) på ditt forslag.

Tror jeg kommer til å bruke din metode uansett, da det gir mindre sjanse for feil. Den er "bombesikker". Igjen, takk!

 

EDIT: Rettet en setning som ga lite mening.

Endret 6. august 2005 av Mikka

[nomore]

ikke noe problem. liker å gjøre ting skikkelig

[Steinmann]

Må aldri lagre data som kan letes opp med en spørring.

Grunnen til at jeg delte opp auksjon og gjenstand er at de egentlig ikke har så mye med hverandre å gjøre, derfor skal de deles opp BF-normalform el no

 

Har tatt endel egene sluttninger i modellen min som du sikkert vil endre.

Men om dette er et betalt oppdrag, ville jeg fått noen til å designe selve databasen for deg, og konsultere rundt den Vil du tjene på i tid bruk, efektivitet, og mulighet for utvidelser

[Oracel]

Tenkte jeg ville komme med noen tips da det er tydelig at du er litt ny når det gjelder det her. Først og fremst, skal du utvikle noe med et substansielt antall tabeller og høy normalisering med MySQL, så bør du bruke en databasemotor som støtter foreign key constraints. Selv bruker jeg InnoDB. Sett så opp slike constraints slik at du sikrer grunnleggende dataintegritet. Dette er viktig.

 

Videre så bør du sette deg ned og tenke nøye over hva du trenger av tabeller (foreslått relasjon i parantes):

* Skal kunder kunne registrere seg?

* Hva slags forhold er det mellom kunder og salgsgjenstander? (etm)

* Kunder og kjøpsgjenstander? (mtm)

* Kunder og adresser? (etm)

* Adresser og poststeder? (etm)

* Auksjonsgjenstander og hva slags kategorier de faller under? (mtm)

* Gjenstander og bilder? (etm)

* Skal du ha mulighet for å legge inn kommentarer/spørsmål? (det bør du)

* Hva med karaktergivning til kjøpere/selgere?

 

(etm = en-til-mange, mtm=mange-til-mange)

 

Allerede nå er man oppe i 11-12 tabeller.

 

Ikke spar på noe, pøs på med alt du kan komme på. Se på hvordan andre auksjonssider fungerer. Deretter tegner du opp et enkelt relasjonsskjema på papir. Bruk blyant, og ha et viskelær klart. Du bør forvente å bruke noen uker på denne prosessen tatt i betraktning det systemet du har tenkt å lage. Iallfall hvis du skal ha det skikkelig.

 

Hvis du heller vil lage et pseudosystem med tre-fire tabeller og svak integritet, så må du ikke forvente femsifrede (eller firesifrede, eller tresifrede) besøk, da systemet ditt vil fremstå som totalt uprofesjonelt og omtrent ubrukelig.

Endret 7. august 2005 av Oracel

[Ueland]

nomore: Tok du og flushet disk cache/MySQL query cache etter hver spørring? Hvis ikke er resultatene ikka akkurat å stole på da den forskjellgen kan være _gigantisk.

[nomore]

nei, det gjorde eg ikke... *hmm*

 

skal endre på det og teste på nytt

[nomore]

de tok faktisk lengre tid nå...

[Ueland]

de tok faktisk lengre tid nå...

Jeg testet med et en Opteron server og da fikk jeg rundt 100 spørringer i sekundet uten cache, mens jeg fikk 30 000 (!) med cache, så det viser hvor "farlig" det er..