10 Almindelige SQL fejl - dummies

Face it - ingen studerer SQL for det sjove af det. Du bruger SQL til at opbygge databaseapplikationer, men før du kan bygge en, skal du have en database. Desværre går mange projekter forkert, før den første linje i applikationen er kodet. Hvis du ikke får databasedefinitionen korrekt, er din ansøgning dømt. Her er ti fælles fejl i databasen, som du skal være på udkig efter.

Antag ikke, at dine kunder ved, hvad de har brug for

Generelt opfordrer kunderne dig til at designe et databasesystem, når de har et problem med at få de oplysninger, de har brug for, fordi deres nuværende metoder ikke virker. Kunder tror ofte på, at de har identificeret problemet og dets løsning. De finder ud af, at alt hvad de skal gøre er at fortælle dig hvad de skal gøre.

Forkert. De fleste brugere har ikke den viden eller de nødvendige færdigheder til at identificere problemet, så de har ringe chance for at bestemme den bedste løsning.

Dit job er at overbevise klienten taktmæssigt, at du er ekspert i systemanalyse og design, og at du skal foretage en ordentlig analyse for at afdække den egentlige årsag til problemet.

Se bort fra projektets anvendelsesområde

Din klient fortæller dig, hvad han eller hun forventer af den nye ansøgning i starten af ​​udviklingsprojektet. Desværre glemmer klienten næsten altid at fortælle dig noget - normalt flere ting. I løbet af arbejdet opstår disse nye krav og bliver tacklet til projektet.

Hvis du bliver udbetalt på projektbasis i stedet for en time, kan denne vækst i omfang ændre det, der engang var et rentabelt projekt til en taber. Sørg for, at alt, hvad du er forpligtet til at levere, er angivet skriftligt, før du starter projektet.

Overvej ikke kun tekniske faktorer

Problemer med omkostningsgrænser, ressourcetilgængelighed, tidsplanskrav og organisationspolitik kan få stor betydning for projektet. Disse problemer kan gøre et projekt, der er muligt i et mareridt. Sørg for, at du forstår alle relevante ikke-tekniske faktorer, før du starter et udviklingsprojekt.

Undgå klientfeedback

Din første tilbøjelighed er at lytte til de ledere, der ansætter dig. Når alt kommer til alt, betaler brugerne helt sikkert ikke dit gebyr. På den anden side kan der være god grund til også at ignorere lederne. De har normalt ikke en anelse om, hvad brugerne virkelig har brug for. Vent et øjeblik!

Undgå at ignorere alle eller antage, at du ved mere end en leder eller bruger om, hvordan en database skal fungere. Data-entry-kontorister har typisk ikke meget organisatorisk indflydelse, og mange ledere har kun en svag forståelse af nogle aspekter af det arbejde, som data-entry clerks gør.Men at isolere dig selv fra begge grupper er næsten sikkert at resultere i et system, der løser et problem, som ingen har.

Du kan ikke altid bruge dit yndlingsudviklingsmiljø

Du har nok brugt måneder eller endda år til at være dygtige i brugen af ​​et bestemt DBMS- eller applikationsudviklingsmiljø. Men dit yndlingsmiljø - uanset hvad det er - har styrker og svagheder.

Så hellere end kludge sammen noget, der ikke rigtig er den bedste løsning, bide kuglen. Du har to muligheder: Du kan enten klatre i indlæringsskurven for et mere passende værktøj og derefter bruge det eller ærligt fortælle dine kunder, at deres job bedst kan gøres med et værktøj, som du ikke er ekspert i at bruge.

Derefter foreslår, at klienten ansætter en person, der kan være produktiv med det værktøj med det samme. Professionel adfærd af denne art skaber dine kunders respekt. (Desværre, hvis du arbejder for et firma i stedet for for dig selv, kan denne adfærd også give dig afskedigelse eller fyret.)

Brug ikke udelukkende din yndlingssystemarkitektur

Ingen kan være ekspert på alt. Databasestyringssystemer, der arbejder i et teleprocessormiljø, er forskellige fra systemer, der arbejder i klient / server, ressourcedeling, webbaserede eller distribuerede databasemiljøer. Vælg den bedste arkitektur alligevel, selvom det betyder at passere jobbet. At ikke få jobbet er bedre end at få det og producere et system, der ikke tjener kundens behov.

Design ikke databasetabeller isoleret

Hvis du fejlagtigt identificerer dataobjekter og deres forhold til hinanden, vil dine databastabeller sandsynligvis introducere fejl i dataene og ødelægge gyldigheden af ​​resultaterne. For at designe en lyddatabase skal du overveje den overordnede organisering af dataobjekter og omhyggeligt afgøre, hvordan de vedrører hinanden. Du skal bestemme, hvad der passer, i betragtning af din kundes nuværende og forventede behov.

Undlad at overse designanmeldelser

Selv den bedste designer og udvikler kan gå glip af vigtige punkter, der er tydelige for, at nogen kigger på situationen fra et andet perspektiv. Præsentere dit arbejde før en formel design review kan gøre dig mere disciplineret i dit arbejde. Få en kompetent faglig vurdering af dit design, før du begynder at udvikle. Du bør have en database designer tjekke det over, men du vil måske også vise det til kunden.

Spring ikke over beta-test

Selvom du tester det på alle måder, du kan tænke på, vil programmet helt sikkert indeholde de fejlfunktioner, du ikke afslører. Betatestning betyder at give ansøgningen til folk, der ikke ved, hvordan den blev designet.

De har sandsynligvis problemer, du aldrig har ramt, fordi du ved for meget om applikationen. Du kan derefter rette fejlene eller ydeevnenes mangler, som andre finder, før produktet bliver officielt taget i brug.

Glem ikke at dokumentere din proces

Hvis du mener, at din ansøgning er så perfekt, at den aldrig skal ses igen, tænk igen.Det eneste du kan være helt sikker på i denne verden er forandring. Tæl på det. Seks måneder fra nu vil du ikke huske, hvorfor du har designet ting som du gjorde, medmindre du omhyggeligt dokumenterer hvad du gjorde, og hvorfor du gjorde det på den måde.

Overdokument dit arbejde. Angiv mere detaljeret end du synes er rimelig. Det vil betale sig senere.