Webkafeen

[LoS]

Skal du drive med statistikk kan det være kjekt å ta vare på. Skal du ikke det så kan du jo bare fjerne alle bud som er gitt til en auksjon som er over.

Skal du ha statistikk ville jeg flytta de over til en annen tabell, de utgåtte budene mener jeg.

Btw, så ville jeg brukt 2 tabeller, tror jeg. En til budene, og en til auksjonene.

[mikk-]

Akkurat. Tror jeg går for en liknende løsning, ja. Sletter alle bud på auksjoner som er gått ut på dato for en uke siden eller noe.

 

 

(Skrev innlegget før jeg så LoS sitt. Skal høre litt med klienten (eller hva pokker man kaller ham). Takk for tips!)

Endret 4. august 2005 av Mikka

[joffar]

Som nevnt, holder jeg på med en auksjonsside, og skal nå begynne å programmere selve auksjonssystemet. Er litt usikker på hvordan jeg skal lage database-delen, og lurte på om noen har noen tips.

 

Må altså ha en måte å lagre selve auksjonene på, og en måte å lagre alle budene som kommer inn på hver enkelt auksjon. Idéelt sett, skulle man ha hatt en tabell for hver auksjon, men jeg tror ikke det er noen løsning da det kan bli ganske mange etter hvert. Mitt eneste forslag er da å lagre alle budene i én database, hvor ett felt bestemmer hvilken auksjon de hører til.

 

Denne tabellen vil dog få veldig mange linjer etter hvert. Har aldri vært borti mySQL av denne størrelsen før. Vil dette systemet bli veldig tregt? Hva med etter, la oss si 100 000 bud?

 

Er det best å lage en funksjon som sletter gamle bud etter hvert?

Tror jeg ville laget en funksjon som arkiverer alle budene i auksjoner som er ferdige. Å slette bud som er etter ett gitt tidspunkt eller som er x antall bud bak det første, kan i værste fall slette bud historien i en aktiv budrunde, noe som vel ikke burde forekomme.

Arkivere ferdige auksjoner og budrunder til en egen db er vel også å foretrekke da dette gir deg muligheten for dokumentasjon dersom noen skulle finne på å klage av en eller annen grunn.

 

Her er mitt forenklete forslag

 

Aktive auksjoner: Active db: Tabell for auksjoner + tabell for bud + tabell for auksjons Item. Der auksjons item har en id som brukes av bud-auskjons tabellene til å knytte dem sammen.

Ferdige auksjoner: Archive db: Tabell for auksjoner + tabell for bud + tabell for auksjons Item. Der auksjons item har en id som brukes av bud-auskjons tabellene til å knytte dem sammen.

 

Det er mulig det er bedre måter å gjøre det på også, men i skrivende stund vil det nok være noe slikt jeg ville gått for.

 

Lykke til

 

Ca det samme som Los foreslo...

Endret 4. august 2005 av joffar

[Lokaltog]

Jeg har hørt at 100 000 rader ikke skal være noe problem for vanlige SQL-servere. Har testet det ut i praksis selv (en tabell med et par millioner rader), og så lenge feltene som det skal gjøres søk i er indekserte, så er det så å si ingen forskjell på hvor mange spørringer som kan utføres i sekundet. Bare husk å indeksere tabellene riktig /før/ du legger til en million rader, det tar nemlig ganske lang tid å legge til indekser på en stor tabell.

[joffar]

Jeg har hørt at 100 000 rader ikke skal være noe problem for vanlige SQL-servere. Har testet det ut i praksis selv (en tabell med et par millioner rader), og så lenge feltene som det skal gjøres søk i er indekserte, så er det så å si ingen forskjell på hvor mange spørringer som kan utføres i sekundet. Bare husk å indeksere tabellene riktig /før/ du legger til en million rader, det tar nemlig ganske lang tid å legge til indekser på en stor tabell.

riktig indexering er viktig dersom en har db med litt størrelse ja...

 

Dersom du har felter i en tabell hvor de samme verdiene gjentas i hver rad, lønner det seg i de fleste tilfeller å lage en egen tabell for disse med en id som linker tilbake til den spesifikke raden...

[mikk-]

Ut ifra innlegget til Lokaltog og denne tråden,slår det meg at dersom jeg indekserer Auksjons-id-feltet, så er det kanskje ikke så farlig med å slette gamle bud? Jeg kan iallfall la det gå en god stund.

 

Forøvrig hjertelig takk for alle svar! Føler meg litt mer "hjelpan" nå

Endret 4. august 2005 av Mikka

[Lokaltog]

Jeg lærte mye av de gode svarene jeg fikk i denne tråden.

 

Et tips er også å kjøre EXPLAIN på noen SELECT-spørringer (jeg synes det er enklest å gjøre det i phpMyAdmin), da finner du fort ut hvor svakhetene ligger og hvilke kolonner du virkelig bør indeksere.

[mikk-]

Kan du forklare det med EXPLAIN litt nærmere? Takk for trådlink også, den hjalp, selv om jeg ikke skjønte skiten.

[Domodyret]

Noen som vil kjøpe mitt eMart-system? Kalt biShop:

 

Link - utvikles fortløpende med nye grensesprengende funksjoner!

[Lokaltog]

Ok, ta dette enkle eksemplet:

 

Jeg har en tabell med ca. 50000 brukere. Jeg vil gjerne hente ut personen med nicket "Lokaltog". Det er enkelt, kjør SELECT * FROM `users` WHERE `nick` = 'Lokaltog'. Hvis du hiver på en EXPLAIN før den spørringen, slik at den blir EXPLAIN SELECT * FROM `users` WHERE `nick` = 'Lokaltog', så får du vite litt nyttig informasjon om hvordan MySQL finner den eller de radene der nicket er Lokaltog.

 

Slik ser resultatet fra EXPLAIN-spørringen ut når det ikke er noen indekser på kolonnen `nick`:

 

 

Hvis jeg nå legger til en indeks på 3 tegn på kolonnen `nick`, ser EXPLAIN-spørringen plutselig helt annerledes ut:

 

 

Slik jeg har forstått det indikerer `rows` hvor mange rader MySQL må lete gjennom for å finne rett rad i tabellen. Med EXPLAIN kan du altså finpusse tabellstrukturen din, fordi du kan se hvor mange rader MySQL leter gjennom, samt hvilke indekser den benytter seg av.

 

Correct me if I'm wrong.

[Loomy]

Noen som vil kjøpe mitt eMart-system? Kalt biShop:

 

Link - utvikles fortløpende med nye grensesprengende funksjoner!

Hallo Kalle Kanon !

 

Du bestilte varene @ 22:27

 

Du bestilte:

fjorten CPUer

¾^√₪ Harddisker

turulf RAM

 

Dette kostet:

 

0 kronúr for CPUkjøp.

0 kronúr for harddiskene.

0 kronúr for RAM-brikkene.

 

Totalt ble det: 0kronúr

[mikk-]

Ah, flott! Hørtes ut som en veldig kjekk funksjon.

 

@Domodyr/Loomy: is_int er nok en fin funksjon

 

EDIT: Nei, forresten ikke. Postdata er jo ikke intreger i utgangspunktet. Eller.. Nå ble jeg litt usikker.

Endret 4. august 2005 av Mikka

[Domodyret]

bla bla bla

Ser du, det er billig å være dum!

[Loomy]

@Domodyr/Loomy: is_int er nok en fin funksjon

 

EDIT: Nei, forresten ikke. Postdata er jo ikke intreger i utgangspunktet. Eller.. Nå ble jeg litt usikker.

Siden PHP ikke "opererer" med faste datatyper, tipper jeg is_int bare er en slags eregi/regexp-sak som sjekker at det bare er gyldige tall.

 

 

EDIT: Eller kanskje ikke

Note:  To test if a variable is a number or a numeric string (such as form input, which is always a string), you must use is_numeric().

Endret 4. august 2005 av Loomy

[Lokaltog]

PHP har jo datatyper, selv om de ikke fungerer på samme måte som datatypene i f.eks. C. Man har heltall, kommatall, strenger, etc., og is_int() sjekker om datatypen er integer (heltall):

 

$var1 = "123";
$var2 = 123;

var_dump(is_int($var1)); // bool(false)
var_dump(is_int($var2)); // bool(true)

[Jernlov]

hey hey hey, back from 1 ukes bann! jeg lurer på en ting, lager sånn meny ved hjelp av en liste sant. men la oss si at jeg skal ha den horizontal. Og jeg har 4 meny valg, og rammen er 600px bred, hva gjør jeg for å dele de opp så hver sånn meny valg er 150px bred liksom? :S

[Domodyret]

 

Fin side

[Abruzzi]

Ja passet bra til innholdet.

[Jernlov]

Takk for hjelpa da!

 

123 - Siden, hvordan får jeg meny valgene til å liksom, ta hele ramma og være like store? anyone??

[Cucum(r)]

"Ta hele ramma"?