boemane Skrevet 20. august 2004 Skrevet 20. august 2004 Jeg driver å skriver en guide til SQL. Jeg er ferdig med kapittel 1-5 som tar for seg select, insert, update og delete, samt where og order by. Jeg arbeider med å blir ferdig med de resterende kapitler innenfor emner som create, drop, alter, normalisering (kort), og programmering med MySQL (PHP 4 og 5) samt JSP (JavaServer Pages): http://sql.devsiden.info/ Si gjerne hva dere synes, og innhold dere kunne ønske dere i guiden.. .:BoeManE:.
Arve Systad Skrevet 21. august 2004 Skrevet 21. august 2004 Serif fonter på web er tunge å lese, så legg dette til i stilarket ditt: body,html { font-family: "trebuchet MS", arial, helvetica, sans-serif; }
kaffenils Skrevet 23. august 2004 Skrevet 23. august 2004 Jeg driver å skriver en guide til SQL. Jeg er ferdig med kapittel 1-5 som tar for seg select, insert, update og delete, samt where og order by. Jeg arbeider med å blir ferdig med de resterende kapitler innenfor emner som create, drop, alter, normalisering (kort), og programmering med MySQL (PHP 4 og 5) samt JSP (JavaServer Pages): http://sql.devsiden.info/ Si gjerne hva dere synes, og innhold dere kunne ønske dere i guiden.. .:BoeManE:. Nå vet ikke jeg hva MySQL støtter av SQL, men det jeg ser med første øyekast er at kapittel 3 f.eks. mangler info om bl.a. å hente data fra flere tabeller (INNER/OUTER/LEFT/RIGHT JOIN), GROUP, UNION. På filtrering forklarer du ingenting om LIKE eller IN. Men det kommer vel Eller synes jeg det er merkelig av du i eksempeldatabasen bruker AvdelingsNavn, som er varchar(50) til primærnøkkel og dermed også fremmednøkkel. Bruker du f.eks. en ny kolonne AvdelingsNummer som primærnøkkel så trenger ikke fremmednøkkel å endres ved endring av AvdelingsNavn.
boemane Skrevet 24. august 2004 Forfatter Skrevet 24. august 2004 (endret) Nå vet ikke jeg hva MySQL støtter av SQL, men det jeg ser med første øyekast er at kapittel 3 f.eks. mangler info om bl.a. å hente data fra flere tabeller (INNER/OUTER/LEFT/RIGHT JOIN), GROUP, UNION. På filtrering forklarer du ingenting om LIKE eller IN. Men det kommer vel Eller synes jeg det er merkelig av du i eksempeldatabasen bruker AvdelingsNavn, som er varchar(50) til primærnøkkel og dermed også fremmednøkkel. Bruker du f.eks. en ny kolonne AvdelingsNummer som primærnøkkel så trenger ikke fremmednøkkel å endres ved endring av AvdelingsNavn. De forskjellige joins er planlagt for et senere kapittel, synes det var litt tidlig å introdusere i kapittel 3 Like og In er også planlagt til senere kapitler. Årsaken til at jeg benytter AvdelingsNavn som primær og fremmed nøkkel er at jeg ønsker at guidene skal være enkle å forstå, med så lite "ekstra" som mulig. Når det er sagt, vil jeg selvfølgelig ta opp dette når jeg skal diskutere SQL nøkler i et senere kapittel, ettersom man i og for seg aldri skal endre en primærnøkkel, selv om MySQL tillater det. Takk for tilbakemelding! .:BoeManE:. Endret 24. august 2004 av boemane
boemane Skrevet 11. september 2004 Forfatter Skrevet 11. september 2004 Jeg driver å skriver en guide til SQL. Jeg er ferdig med kapittel 1-5 som tar for seg select, insert, update og delete, samt where og order by. Kapittel 6 til 8 er nå lagt ut... Kapittel 6 tar for seg oppretting, manipulering og sletting av tabeller. Kapittel 7 tar for seg de fire typene nøkler: Kandidat-, Primær-, Fremmed- og ikke-nøkler. Kapittel 8 tar for seg sammenkobling av tabeller, indre og ytre joins. http://sql.devsiden.info/ .:BoeManE:.
boemane Skrevet 30. september 2004 Forfatter Skrevet 30. september 2004 Sida nede? Det ser ut som om Tomcat ikke fungerer som det skal på serveren. Har tatt kontakt med ISPen, men venter fortsatt på svar. Siden er nok i hvertfall oppe igjen i løpet av 24 timer.
boemane Skrevet 2. oktober 2004 Forfatter Skrevet 2. oktober 2004 Ser ikkje sånn ut Nei, det er beklagelig! Jeg har vært i kontakt med webhosten flere ganger, og de jobber vistnok med å fikse problemet. Jeg kan legge inn en post her når siden er oppe igjen. Plagsomt når webhosten gjør slike feil! nå man skulle ønske at man hadde en dedikert server... Men, men
boemane Skrevet 2. oktober 2004 Forfatter Skrevet 2. oktober 2004 Ser ikkje sånn ut Nei, det er beklagelig! Jeg har vært i kontakt med webhosten flere ganger, og de jobber vistnok med å fikse problemet. Jeg kan legge inn en post her når siden er oppe igjen. Plagsomt når webhosten gjør slike feil! nå man skulle ønske at man hadde en dedikert server... Men, men Da var problemene hos webhosten fikset, og alt ser ut til å fungere som normalt igjen. I tillegg er kapittel 9 og 10 lagt ut: Kapittel 9 tar for seg avansert filtrering i SQL, filtrering ved hjelp av mønster, samt nøkkelordene in og not. Kapittel 10 tar for seg normalisering av databaser, og de tre viktigste normalformene http://sql.devsiden.info/ .:BoeManE:.
pgdx Skrevet 13. februar 2005 Skrevet 13. februar 2005 Det står ikke noe om lisens, gjør det? Er det under FDL?
kaffenils Skrevet 14. februar 2005 Skrevet 14. februar 2005 Det står ikke noe om lisens, gjør det? Er det under FDL? Lisensiering har ingenting med SQL å gjøre.
pgdx Skrevet 14. februar 2005 Skrevet 14. februar 2005 Jeg mente guiden han har skrevet. Derav FDL...
kaffenils Skrevet 14. februar 2005 Skrevet 14. februar 2005 Jeg mente guiden han har skrevet. Derav FDL... Seff!! Er bare jeg som er litt treig i dag.
boemane Skrevet 21. mars 2005 Forfatter Skrevet 21. mars 2005 Det står ikke noe om lisens, gjør det? Er det under FDL? Er det lisens til å gjenbruke koden du mener, er det bare å bruke som du ønsker... .:BoeManE:.
Frankium Skrevet 20. august 2005 Skrevet 20. august 2005 Bra side, fint å ha en SQL tutorial på norsk når jeg må friske opp kunnskapene
roac Skrevet 10. januar 2006 Skrevet 10. januar 2006 Utifra de tre kandidatnøklene overfor utelukker vi kandidatnøkkel nummer 3 som primærnøkkel, ettersom det er den eneste av kandidatnøklene som er bygget opp av flere kolonner. Selv om kolonnen Personnr. unikt identifiserer samtlige rader i tabellen, kan vi tenke oss situasjoner hvor det kan være upraktisk å identifisere kunder ved hjelp av person nummeret. Kandidatnøkkel 1, Kundenr, bør dermed defineres som tabellens primærnøkkel. Det er faktisk større sannsynlighet for at kundenummer vil være upraktisk (sammenslåing av to selskaper), enn personnummer (en person skifter kjønn). En god tommelfingerregel er at primærnøkkelen ikke skal ha noen mening ut over å være primærnøkkel, også kjent som surrogatnøkkel.
swj Skrevet 4. april 2006 Skrevet 4. april 2006 (endret) edit- så etterpå at dette ikke var rette plassen å poste spørsmål. Beklager. Fint om dere sletter innlegget mitt Endret 4. april 2006 av swj
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å