Modelleringsproblem for relasjonsdatabase

[magnekd]

Har et problem jeg ikke klarer å modellere:

En artikkel skal kunne bestilles i et visst antall, for hver uke. Dvs artikkel tabellen er f.eks.

 

Artikkel

ArtID

ArtNavn

 

Problemet er at i uke 2 skal det gå an å bestille for de 4 neste ukene (3,4,5,6), og dette skal endre seg autmatisk etterhvert som ukene går. Bestillingsskjemaet skal se ut som noe slik (3,4,5,6 er ukenr)

 

Artid__Artnavn__3 4 5 6

0001__Bjarne___ 0 0 2 3

0002__Rolf_____ 1 2 0 4

 

Problemet er at jeg ikke vet hvordan jeg skal modellere for at jeg kan gjøre en spørring som viser de 4 neste ukene, og en spørring som oppdaterer de 4 neste ukene.

 

Hvis noen kan hjelpe meg med et ER-diagram, en relasjonstabell eller SQL-spørringer ville jeg vært veldig takknemlig!

[Manfred]

Jeg lukter skoleoppgave...

[roac]

Småekkel sådann. Ikke vanskelig å løse, men jeg funderer fortsatt på hva som vil være den beste løsningen

[Manfred]

Det er litt for mye jobb til at jeg gidder å løse oppgaven til noen. Hehe. Men jeg synes det er litt mye å be om ER-diagram, relasjonstabell eller SQL-spørringer. Det rette vil vel heller være å bli pekt i rett retning.

[magnekd]

Er ikke skoleoppgave, men noe jeg gjør for en bedrift. Jeg har allerede en løsning, men jeg mistenker at det finnes en bedre en!

 

ER-diagram, SQL eller relasjonstabeller er da bra måter å forklare databaser på, fremfor tekst? Ikke?

[roac]

ER, SQL også videre er tyngre å skrive, og hvis vedommende kan det han holder på med ikke nødvendig, da duger tekst helt fint

 

En funksjon for ukenummer kommer du ikke utenom, og etter det jeg kan se har du ikke behov for datoer. Da kan du fint bruke et check-constriant for innsetting, som validerer at ukenummeret. Bruk ukenummeret (om så bare "internt") på formen yyww og sjekk ukenummeret for dagen om 7 dager og 28 dager, og sjekk at innsatt ukenummer faller innenfor det intervallet.

 

Noe ekstra tabellverk eller modifisering av tabellverk er det overhodet ikke behov for.

[magnekd]

ER, SQL også videre er tyngre å skrive, og hvis vedommende kan det han holder på med ikke nødvendig, da duger tekst helt fint

 

Dette krever dessverre at vedkommende som skal forstå (les meg) også kan de han holder på med... og det er det ingen garanti for

 

Mener du at jeg skal ha en Artikkeltabell(ArtID, Artnavn) , og en Bestillingstabell(ArtID, Uke, Bestilling) og at Uke skal genereres automatisk av DBS ved en funksjon?

 

Tusen takk for hjelp!

[roac]

Ja og nei.

 

Gyldige ukenumre kan genereres enten på klinentsiden eller serversiden, men du kan uansett ikke stole på ukenummeret som kommer når en bestilling lagres i detabasen, så du må ha en check-constraint som validerer ukenummeret.

[magnekd]

Ja og nei.

 

Gyldige ukenumre kan genereres enten på klinentsiden eller serversiden, men du kan uansett ikke stole på ukenummeret som kommer når en bestilling lagres i detabasen, så du må ha en check-constraint som validerer ukenummeret.

8042813[/snapback]

 

Akkurat. Hvis jeg forstår deg riktig er dette slik jeg har det idag (uten constraints vel og merke, så det skal jeg legge til). En Bestillingstabell(ArtID, Uke, Bestilling) hvor serversiden av applikasjonen genererer ukenr i nettsiden, og gjør spørringer etter disse ukenr/artid. Hvis ikke de finnes vises 0, ellers vises tallet som finnes. Problemet er jo at det blir jo voldsomt med rader etterhvert i Bestillingtabellen. Med 200-300 artikler, etter dette systemet har kjørt ett år...

[roac]

Hva er problemet? Det er jo hele poenget med databaser. Jeg jobber daglig med millioner av rader, og det går som en drøm.

[tZar]

Så lenge man indekserer riktig og kun viser relevante data, så er ikke mange millioner rader noe problem i selve databasen.

 

Ang ukenummer så finns det i de fleste databaser ferdige funksjoner som du kan benytte i sql'en for å hente ut rader for bestemte uker, selv om du feks bruker et vanlig dato felt for lagring av bestillingen, feks:

 

select a.navn, a.beskrivelse from artikkler a inner join bestillinger b on a.aid=b.faid where week(b.bestillingsdato)=5 and year(b.bestillingsdato)=2007;

 

[artikkler]

aid

navn

beskrivelse

 

[bestillinger]

bid

faid

bestillingsdato

[roac]

Etter det jeg kan se og huske (uten å ha sjekket grundigere) støtter verken week i MySQL eller datepart i MSSQL ukenumre hvor uke 1 er første firedagersuke, slik vi bruker i Norge. Men, noen må gjerne korrigere meg hvis jeg tar feil

[tZar]

Med parameteren '1' i MySQL så burde vel de norske ukene være støttet, uten at lokale dato-varianter er min sterkeste side

[roac]

Med parameteren '1' i MySQL så burde vel de norske ukene være støttet, uten at lokale dato-varianter er min sterkeste side

8059042[/snapback]

Det måtte være noe jeg hadde oversett, jo da, det skal funke

[siDDis]

Er ikkje Noreg omtrent det einaste landet i verda som bruker veker? Eg hugse eg hadde ein skuleoppgåve med det og enda opp med å bruke eit javabiblotek for å ta seg av veker som blei lagra som ein rein int inni databasen. Rein hack, men for ting som ikkje er standard så blir det bare sånt

[magnekd]

Takk for alle svar! Jeg tror jeg konkluderer med at det ikke kan gjøres på en annem måte enn jeg allerede har gjort det, og at det blir mange rader ikke har noen betydning for ytelsen.

 

Nok en gang, takk for all hjelp!

 

edit: skrivefeil

Endret 6. mars 2007 av magnekd