Hejsan!

Jag en databas med frågor där kolumnerna är id | fråga | påstående1 | påstående2 | påstående3

Jag vill hämta alla frågor inom ett givet intervall, detta gör jag med följande sats

Set rstRS = Connect.execute("SELECT Id, Fraga , Pst1, Pst2, Pst3 FROM Fragor Where id between " & intStartPosition & " and " & intStartPosition + intAntalTal - 1)

arrOrdnadeFragor = rstRS.GetRows()

Problemet är att om intervallet är större än 5 så hamnar frågorna inte längre i följd i arrayn...
Då hamnar alla frågor efter de 5 första slumpvis i arrayn och sist kommer de 5 första... I FÖLJD.... fattar inget...

Någon som kan förklara?

mvh /Alex

Sortera resultatet:

Set rstRS = Connect.execute("SELECT Id, Fraga , Pst1, Pst2, Pst3 FROM Fragor Where id between " & intStartPosition & " and " & intStartPosition + intAntalTal - 1 & " ORDER BY id")

/Johan

Tackar!

Funkade jättebra!

<b>Pst1, Pst2, Pst3 </b>
Hmmm... Hört talas om normalisering?

<b>Hmmm... Hört talas om normalisering?</b>

Vad är det? Berätta gärna mer då jag själv ibland namnger flera fält så där.


Thomas

<b>Berätta gärna mer då jag själv ibland namnger flera fält så där.</b>

Tror inte att han syftar på namnstandard utan på designen av databasen... Normalisering är något grundlägande för databaser, kan man inte normalisera till 3'e graden så skall man INTE hålla på med att designa databser. Exakt vad det är får du fram genom att söka på Google, fins många siter som förklarar det enklare och bättre än vad jag kan.

Vad är det här för hårda ord?

Jag har precis börjat med ASP och Databaser... och på aspsidan har dem inte sagt något om normalisering... hur ska man då veta? "kan man inte normalisera till 3'e graden så skall man INTE hålla på med att designa databser".... suck...

så att så länge jag inte kan detta så får jag inte hålla på med databaser... (ironi)

trams!

Normalisering handlar om hur man designar databaser. Hur man "ska" göra är lite beroende på hur du använder din tabell. Är det alltid 3 Pst*? I sådana fall är din design helt ok (utan att gå in på nägra detaljer). Om man följer alla normaliseringsregler (jag är lite osäker på några av dom) kan man få sämre prestanda.

/Johan

Hårda ord? Nja, snarae sanning... Ungefär som att kan man inte trafikregler så skall man inte ut och köra bil i trafiken. Normalisering är något grundläggande för databaser och innan man försöker göra något med databaser bör man ha en viss förståelse för hur de fungerar och hur man bygger upp dem och där kommer normalisering väldigt högt upp. För mig är det lika självklart som att vet man inte skillnaden mellan en sträng och en int så skall man inte programmera utan försöka skaffa sig en viss förförståelse innan man börjar.

<b>på aspsidan har dem inte sagt något om normalisering</b>
På aspsidan? Vill du göra bra databser så köp en bok om hur de fungerar och byggs upp, kan rekommendera en bok av en kille som heter "Date" (kommer inte ihåg titeln just men Database systems eller nåt sånt, det står om den i forumet så testa att söka).

Hur du vill tolka det jag skrev lämnar jag till dig, tycker du att det är trams att jag upplyser om att det finns något grundläggande i dina kunskaper om databaser du har missat så att du kan lära dig det så får du gärna göra det. Frågar du på ett forum så kommer du att få synpunkter på din lösning, både på sådant du har gjort bra och det du har gjort mindre bra. Se det istället som att du har fått en upplysning om en kunskap du har missat och att du nu kan inhämta den och förhoppningsvis ta till dig den och få en inblick i hur man designar databaser. Tror att normalisering kom på första föreläsningen om databaser när jag pluggade.

Gjorde en snabb sökning på "normalisering", första svenska var: http://www.pmdatautbildning.se/webbkurs/db/5DB.htm Det finns mer än 3'e normalformen men oftast räcker det med med att normaliser till den.

Angående hårda ord.

Det är rätt att man inte får ge sig ut i trafiken, i alla fall inte själv, innan man lärt sig regler och hur man ska köra, MEN man får ge sig ut och övningsköra i trafiken med lämplig hjälp som t ex en körskoleklärare som på ett bra sätt kan lära ut hur man bör bete sig.

Ungefär det samma gäller väl även för databasdesign, har man inte rätt kunskaper så ska man inte ge sig ut i trafiken (skarp applikation) på egen hand däremot kan man ju labba med egna applikationer (övningsköra) för att lära sig mer.

Det är ju svårt att börja med något om man inte får börja med det förrän man kan det.

Marcus, vore det inte bättre i detta fall att tipsa om någon konkret referens till information om normalisering, du borde ju ha sådana efersom du själv verkar lärt dig det någonstans.


På pellesoft: Artikel [Normalisering, vad är det?] och några korrigeringar/kompletteringar till den finns här Artikel [Normalisering - ett komplement]

http://www.pmdatautbildning.se/webbkurs/db/index.htm En liten enkel databaskurs
http://support.microsoft.com/default.aspx?scid=kb;en-us;283878

<b>Marcus, vore det inte bättre i detta fall att tipsa om någon konkret referens till information om normalisering, du borde ju ha sådana efersom du själv verkar lärt dig det någonstans.</b>

Jag tipsade om den bästa källan som finns, nämligen Date's bok som har varit uppe på forumet ett antal gånger. Att det fanns artiklar om det på pelleoft visste jag inte, jag skummade snabbt igen den första och den kan säkert vara bra för att få en snabb överblick men jag hittade så grova sakfel så den kändes inte rätt om man ville ha mer än nybörjarkunskaper.

Om någon tolkar det som hårda ord så får dem göra det, jag ser det som att en "brist" har påpekats och att det finns möjligheter att åtgärda det. Bättre att få en brist påpekad och ha en möjlighet att åtgärda det än att hålla tyst om det och låta någon fortsätta göra fel, sedan är ju skrift på nätet en "kantig" form av kommunikation.

Mer om normalform på http://www.datamodel.org/NormalizationRules.html och till skillnad från artikeln på pellesoft (som säger att det finns tre normaliseringsnivåer enbart) så visar den övriga normailseringsregler mm. Sista sidan på denna är otroligt bra http://www.databasejournal.com/sqletc/article.php/1428511 Wikipeda har ju såklart definitioner på normalisering: http://en.wikipedia.org/wiki/Database_normalization Boken jag tipsade om: http://www.aw-bc.com/catalog/academic/product/0,1144,0321197844,00.html Kolla på "Further Reading" under wikipedalänken vilken författare de hänvisar till.

<b>Hårda ord? Nja, snarae sanning... Ungefär som att kan man inte trafikregler så skall man inte ut och köra bil i trafiken. Normalisering är något grundläggande för databaser och innan man försöker göra något med databaser bör man ha en viss förståelse för hur de fungerar och hur man bygger upp dem och där kommer normalisering väldigt högt upp. För mig är det lika självklart som att vet man inte skillnaden mellan en sträng och en int så skall man inte programmera utan försöka skaffa sig en viss förförståelse innan man börjar. </b>


Jag kan inte annat än hålla med om att det är viktigt att förstå normalisering när man jobbar med databaser. Men alla är barn i början, och du behöver ju inte "dissa" dem som inte kan lika mycket som dig. Försök hjälpa till istället. Det är vad den här sajten går ut på =)

Det är som sagt bra att känna till normalisering. Och ju mer man kan om det, desto bättre databaser kommer man att utveckla. Men det betyder inte att man alltid bör normalisera till 3NF. Det är ibland onödigt och kontraproduktivt. Normalisering går ut på att lagra data så effektivt som möjligt. Det mest grundläggande syftet är att spara plats, så att t.ex. texten "STOCKHOLM" inte lagras 10.000 grr i ett system utan bara en gång. Normalisering uppfanns i en tid då en fet hårddisk var på 10 MB och då fanns det stor anledning att komprimera datalagringen så mycket som möjligt. I dag spelar det ingen större roll om din databas är på 50 eller 500 MB eftersom disk är så billigt. I dag är det många som tänker åt andra hållet och väljer att denormalisera i stället. Att inte överdriva normaliseringen har två fördelar:
1. Man får enklare SQL både för hämtning och uppdatering av data. Det tar längre tid att utveckla frågor i en högt normaliserad databas pga att man måste skriva fler joins. Att uppdatera/sätta in ny data i en mkt normaliserad databas kräver betydligt mer kod och CPU.
2. Prestandan ökar inte av att du måste gör 10 joins i varje select-fråga. Utan tvärtom, det kostar naturligtvis mer CPU när fler tabeller är inblandade i en fråga.
Normalisering är bra men man bör alltid användas ihop med sunt förnuft.

Förstår inte riktigt vad du menar med att jag "dissar" någon. jag skrev i mitt flrsta inlägg: "Normalisering är något grundlägande för databaser, kan man inte normalisera till 3'e graden så skall man INTE hålla på med att designa databser." och det står jag vid, däremot så kan man naturligtvis lära sig vad normalisering är och tillämpa det. Mitt inlägg var menat på att peka på en frundläggande kunskapsbrist som behövs rättas till innan man har gått alltför långt i designen av ett system.

Marcus, när du säger åt folk att INTE (med versaler) hålla på med databaser bara för att de inte behärskar normalisering upp till 3NF så är det att dissa personen i fråga. Det är ganska onödigt. Hjälp till i stället för att mästra över andra, så blir detta ett mycket trevligare forum för alla.

Jag värderar underhål högt. Då det flesta applikationer är fattigt dokumenterade eller helt odukomenterade kan en vettig datastruktur underlätta. Jag finner att normaliserade databaser är lättare att underhålla och inte lika grötiga som prestandaoptimerade och eller slarviga databaser.

Men i detta fall föreslog jag att frågeställaren skulle titta närmare på normalisering för strukturen såg ut att vara dynamisk eller kunder underlättas genom att göra dynamisk.
Om antalet varierar krävs det databasförändringa om den övre gränsen skall förändras. Finns ofta en dag då man kommer till den insikten att ett tidigare antaganden gräns sprängs. Ta till exempel 2000 problemet.
Genom att istället lagra posterna i en separat tabell kan antalet alternativ dynamiskt förändras. Utan att kod eller datastruktur behöver förändras. Med andra ord ser jag det som att kvaliteten och underhållet högre.