Tips for å designe en bedre SQL database

Share

|

Holde følgende emner tanke på å sikre at databasen design og oppdateringer gå greit.

Ikke utforme en database som Copes med normen. Fristende som det er å utforme en database som dekker de fleste situasjoner, gjør det er farlig. Det uventede skjer akkurat når du minst venter det, så sørg for at du designe din database for å dekke alle situasjoner som kan oppstå, eller i det minste sørge for at det kan takle uvanlige situasjoner. Selv om en klient forteller du ikke å bekymre seg om muligheten for to personer forsøkte å bestille den samme Hytte samtidig, antar at det vil skje.

Velg meningsfylte navn for tabeller og felt. Prøv å bruke feltet og tabellnavn som bidrar til å gi en idé om hvilke data de store. For eksempel MemberDetails tabellen butikkene medlemmenes detaljer, som gjør det ganske åpenbart uten nærmere forklaring hva tabellen inneholder. Navn tabeller slik at ytterligere forklaring eller se i tabellen er unødvendig. Det samme gjelder kolonnenavn.

Prøv å holde navnene enkel. Kanskje dette synes å motsi den forrige punkt, men det gjør ikke: navn bør være så beskrivende som mulig, men de bør ikke være altfor lange eller komplekse. Lange navn, øker sannsynligheten for feil.

Vær konsekvent i navngiving og valg av datatype. For å hindre forvirring, ikke ringe et felt Postnummer i én tabell og Postnr i et annet hvis de refererer til de samme dataene. Pass også på at begge feltene har samme datatype og kan lagre den samme bredden på data. Hvis du definerer en som varchar (12) i én tabell og varchar (8) i en annen, du risikerer trunkering hvis du skulle sette inn fra én tabell til en annen.

Analysere dataene dine behov på papir først. Det er veldig fristende når du bedt om å lage en database til rush av og begynne å designe på fly, som det var. Men ta deg tid til den første til å sette seg ned med penn og papir og vurdere hvilke data som må lagres og, viktigst, hva svarer databasen er forventet å levere. Hvis personen trenger databasen allerede opererer noen andre system (for eksempel en papirbasert lagersystem), ta en titt på det og bruke den som utgangspunkt for data input.

Velg en primærnøkkel nøye. Velg et felt som er lite sannsynlig å endre og fortrinnsvis en som er en hel-tall basert på feltet. Primærnøkkelen må alltid være unikt. Hvis ingen felt er åpenbar, og deretter opprette ditt eget hel-nummer feltet for å skape en unik primærnøkkel.

Opprette en indeks. Indekser hjelpe fremskynde søk, så å legge dem til felt som regelmessig brukes i søk eller møter er verdt. Indekser er spesielt verdt der du har mange ulike verdier, for eksempel Postnummeret feltet i MemberDetails tabellen. Inkludert en indeks ikke er en god ide, men hvis du bare har noen verdier, for eksempel MemberAttended kolonne i Tilskuere tabellen. Indekser også tregere dataregistrering, noe som spesielt viktig å være oppmerksom på dersom søylen er sannsynlig at mange setter inn eller oppdateringer.

Legg til en fleirkolonnar indeks. Fleirkolonnar indekser komme spesielt hendig i felt der brukerne ofte søke i mer enn én kolonne. For eksempel, hvis du ofte søker etter by og stat sammen, legge til en indeks basert på både kolonner.

Unngå bruk av reserverte ord som bord eller feltnavn. Reservert ord er ord som brukes av SQL språk og er derfor reservert for bruken bare. For eksempel ord som velger, join og indre er eksklusive for SQL. Selv om du kan noen ganger bruke reserverte ord ved å sette klammeparenteser rundt dem, unngå dem helt og holdent er enklere.

Vurder lagringsplass krav. Når du velger et felt datatype, tillater maksimal lagringsplass sannsynligvis være nødvendig, og deretter legge litt! Hvis du tror det største antallet tegn som skal lagres er trolig 8, lage din definisjon 10, eller varchar (10). Doing legger så en liten bit av et sikkerhetsnett. Det samme gjelder med tall.

---