I forventning om starten af det næste flow på hastigheden Vi har udarbejdet et lille forfattermateriale med vigtige tips til at designe en database. Vi håber, at dette materiale vil være nyttigt for dig.
Databaser er overalt: fra de enkleste blogs og mapper til pålidelige informationssystemer og store sociale netværk. Om databasen er enkel eller kompleks er ikke så vigtigt, da det er vigtigt at designe den korrekt. Når en database er designet tankeløst og uden en klar forståelse af formålet, er det ikke kun ineffektivt, men videre arbejde med databasen vil være en reel smerte, en uigennemtrængelig skov for brugerne. Her er nogle tips til databasedesign, der hjælper dig med at skabe et nyttigt og brugervenligt produkt.
1. Bestem, hvad bordet er til, og hvad dets struktur er
I dag hjælper udviklingsmetoder som Scrum eller RAD (Rapid Application Development) it-teams med at udvikle databaser hurtigt. Men i jagten på tid er fristelsen meget stor til at dykke direkte ned i at bygge en base, vagt forestillende, hvad selve målet er, hvad de endelige resultater skal være.
Det er, som om holdet er fokuseret på effektivt, hurtigt arbejde, men dette er et fatamorgana. Jo længere og hurtigere du dykker ned i dybden af projektet, jo mere tid vil det tage at identificere og ændre fejl i databasedesignet.
Så den første ting du skal beslutte dig for er at definere formålet med din database. Hvilken type applikation udvikles databasen til? Vil brugeren kun arbejde med poster og skal være opmærksom på transaktioner, eller er han mere interesseret i dataanalyse? Hvor skal basen indsættes? Vil det spore kundeadfærd eller blot administrere kunderelationer?
Jo hurtigere designteamet besvarer disse spørgsmål, jo glattere vil databasedesignprocessen være.
2. Hvilke data skal jeg vælge til opbevaring?
Planlæg forud. Tanker om, hvad webstedet eller systemet, som databasen er designet til, vil gøre i fremtiden. Det er vigtigt at gå ud over de simple krav i de tekniske specifikationer. Bare lad være med at tænke på alle de mulige typer data, som en bruger nogensinde vil gemme. Tænk bedre over, om brugere vil være i stand til at skrive indlæg, uploade dokumenter eller billeder eller udveksle beskeder. Hvis dette er tilfældet, skal du allokere plads til dem i databasen.
Arbejd med teamet, afdelingen eller organisationen, som designbasen vil blive understøttet for i fremtiden. Kommuniker med mennesker på forskellige niveauer, fra kundeservicespecialister til afdelingsledere. På denne måde får du ved hjælp af feedback en klar idé om virksomhedens krav.
Uundgåeligt vil brugernes behov inden for selv samme afdeling være i konflikt. Hvis du støder på dette, skal du ikke være bange for at stole på din egen erfaring og finde et kompromis, der passer til alle parter og opfylder det ultimative mål med databasen. Vær sikker: i fremtiden vil du modtage +100500 i karma og et bjerg af småkager.
3. Modeldata med omhu
Der er flere nøglepunkter, man skal være opmærksom på, når man modellerer data. Som vi sagde tidligere, afhænger formålet med databasen af, hvilke metoder der skal bruges til modellering. Hvis vi designer en database til online registreringsbehandling (OLTP), med andre ord til oprettelse, redigering og sletning af poster, bruger vi transaktionsmodellering. Hvis databasen skal være relationel, så er det bedst at bruge multidimensionel modellering.
Under modellering bygges konceptuelle (CDM), fysiske (PDM) og logiske (LDM) datamodeller.
Konceptuelle modeller beskriver enheder og de typer data, de inkluderer, samt relationerne mellem dem. Del dine data op i logiske bidder – det gør livet meget nemmere.
Det vigtigste er mådehold, overdriv det ikke.
Hvis en enhed er meget svær at klassificere i ét ord eller en sætning, så er det tid til at bruge undertyper (underordnede enheder).
Hvis en entitet fører sit eget liv, har attributter, der beskriver dens adfærd og dens udseende, såvel som forhold til andre objekter, så kan du trygt bruge ikke kun en undertype, men også en supertype (forælderentitet).
Hvis du forsømmer denne regel, vil andre udviklere blive forvirrede i din model og vil ikke fuldt ud forstå dataene og reglerne for, hvordan de indsamles.
Konceptuelle modeller implementeres ved hjælp af logiske modeller. Disse modeller er som en køreplan for fysisk databasedesign. I den logiske model identificeres forretningsdataenheder, datatyper bestemmes, og status for regelnøglen bestemmes, der styrer relationerne mellem data.
Derefter sammenlignes den logiske datamodel med den forudvalgte DBMS (database management system) platform, og der opnås en fysisk model. Den beskriver, hvordan data opbevares fysisk.
4. Brug de rigtige datatyper
Brug af den forkerte datatype kan resultere i mindre nøjagtige data, vanskeligheder med at samle tabeller, vanskeligheder med at synkronisere attributter og oppustede filstørrelser.
For at sikre informationsintegritet skal en attribut kun indeholde datatyper, der er acceptable for den. Hvis alder er indtastet i databasen, skal du sikre dig, at kolonnen gemmer heltal på maksimalt 3 cifre.
Opret et minimum af tomme kolonner med en NULL-værdi. Hvis du opretter alle kolonner som NULL, er dette en stor fejl. Hvis du har brug for en tom kolonne til at udføre en specifik forretningsfunktion, når dataene er ukendte eller endnu ikke giver mening, så er du velkommen til at oprette den. Vi kan trods alt ikke udfylde kolonnerne "Dødsdato" eller "Afskedigelsesdato" på forhånd; vi er ikke forudsigere, der peger fingre mod himlen :-).
De fleste modelleringssoftware (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) data giver dig mulighed for at oprette prototyper af dataregioner. Dette sikrer ikke kun den korrekte datatype, applikationslogik og god ydeevne, men også at værdien er påkrævet.
5. Gå naturligt
Når du beslutter, hvilken kolonne i en tabel der skal bruges som nøgle, skal du altid overveje, hvilke felter brugeren kan redigere. Vælg dem aldrig som nøgle – en dårlig idé. Alt kan ske, men du skal sikre dig, at det er unikt.
Det er bedst at bruge en naturlig eller forretningsnøgle. Det har en semantisk betydning, så du undgår duplikering i databasen.
Medmindre forretningsnøglen er unik (fornavn, efternavn, position) og gentages i forskellige rækker i tabellen, eller den skal ændres, så skal den genererede kunstige nøgle udpeges som den primære nøgle.
6. Normaliser med måde
For effektivt at organisere data i en database skal du følge et sæt retningslinjer og normalisere databasen. Der er fem normale former at følge.
Med normalisering undgår du redundans og sikrer integriteten af de data, der bruges i din applikation eller dit websted.
Som altid skal alt være med måde, selv normalisering. Hvis der er for mange tabeller i databasen med de samme unikke nøgler, så er du blevet revet med og overnormaliseret databasen. Overdreven normalisering påvirker databasens ydeevne negativt.
7. Test tidligt, test ofte
Testplan og korrekt test bør være en del af databasedesign.
Den bedste måde at teste din database på er gennem kontinuerlig integration. Simuler et "dag i en databases liv"-scenarie og tjek, om alle edge-sager er håndteret, og hvilke brugerinteraktioner der er sandsynlige. Jo hurtigere du finder fejl, jo mere sparer du både tid og penge.
Dette er blot syv tips, som du kan bruge til at designe en fantastisk database over produktivitet og effektivitet. Hvis du følger dem, vil du undgå de fleste hovedpine i fremtiden. Disse tips er kun toppen af isbjerget inden for databasemodellering. Der er et stort antal life hacks. Hvilke bruger du?
Kilde: www.habr.com