Jeg driver å leker meg med tanken på utvikling av en app, og har i den forbindelse lyst til å teste konseptet før jeg faktisk begynner å utvikle selve appen. Uten å gå for mye inn på hva appen skal gjøre, så er det i grove trekk å gjøre forskjellige søk i en relativt stor database basert på ulike kriterier.

Jeg har sett på noen videoer om databasedesign, og ser at applikasjoner for selve designet av databasen er ganske likt i forskjellige applikasjoner. Jeg bruker diagrammet i MySQL Workbench.

Det å sette opp tabeller og relasjoner er en ting, men jeg skulle gjerne ha testet databasen underveis. Er det slik at jeg selv må populere databasen, for så å skrive manuelle queries for hvert scenario jeg vil teste? Eller finnes det noen applikasjoner hvor testing av databasen kan gjøres raskere/enklere?


Vanligvis når man jobber med scripting/programmering så kan man som oftest bryte ned ting i mindre deler, for så å jobbe seg stegvis fremover, dette føles imidlertid litt vanskelig når det kommer til databasedesign. Personlig så synes jeg det er ganske krevende å definere hvilke data som burde lagres i referansetabeller osv, da jeg føler at jeg må se hele databasen i ett.

Finnes det noen gode workflows/fremgangsmåter for å kunne bryte ned design av en kompleks database i mindre og mer oversiktlige deler? Noen som har lyst til å dele sine fremgangsmåter når det kommer til dette? Er det ellers noen som har generelle tips i forhold til databasedesign og testing?

Det dukker ofte opp tråder som ligner på denne, og et gjennomgående problem er at du ikke forteller nok om idéen din til at vi kan si noe som helst intelligent om hvordan du kan løse utfordringene dine.

Bare for å adressere dette først; en idé er ikke verdt noe som helst. Hvis du nå i dag fikk tak i hele kildekoden, infrastrukturen og kundedata for en eksisterende, stor tjeneste - for eksempel Netflix, Google eller Facebook, så ville du ikke blitt millionær over natten. Det du sitter med er en verdiløs idé og et verdiløst system. Det er implementasjonen av en idé som har en verdi. Jeg synes derfor det er unødvendig å være paranoid for at noen skal stjele idéen din. Sjansen for at din idé er original er ufattelig liten. Det kan godt hende at du er den personen som klarer å lage en implementasjon av idéen som blir en suksess; men idéen i seg selv er (mest sannsynlig) ikke original, og jeg kan nesten garantere at noen andre allerede har prøvd å feilet på samme prosjekt.

Anyway.

Testing av databaser er en vanskelig sak. Personlig så mener jeg at det er den beste approachen å fylle opp databasen selv og lage et realistisk testmiljø. Det vil alltid dukke opp problemer som ikke har noen direkte tilknytting til databasen, og den eneste måten du kan teste med "alle variabler" er å sette opp et helt realistisk testmiljø med ekte data. Jeg kan ikke se at du skriver noe om hva slags testing det er du ønsker å gjøre, men jeg regner med det er snakk om performance-testing. Igjen - det er best å gjøre dette mot en så realistisk kopi av databasen som mulig, slik at du også får sjekket at harddisker og nettverk fungerer.

Når det kommer til søkefunksjoner, så er det gjerne en fordel å prøve å unngå for komplekse indekser i databasen. Indekser kan gjøre mer skade enn nytte når verdiene blir for komplekse. Et annet viktig element er caching. Google har et veldig smart system for dette som i korte trekk går ut på at populære oppslag blir løftet lengre frem i systemet. Alt som handler om Trump ligger veldig nære "overflaten" og er lett tilgjengelig for brukerne. Mer abstrakte ting som ingen noen gang søker på ligger langt nede og vil ta lengre tid å søke opp.

Ta en titt på første, andre og tredje normalform (1NF, 2NF, 3NF). Det kan ta tid å forstå seg på, men plutselig knekker man koden, og da kan man se hensiktsmessige inndelinger av tabeller og kolonner med det blotte øyet.

Som andre har påpekt, er det vanskelig å anbefale noe uten å vite hva som skal gjøres, men du kan se på NoSQL om du er usikker på hva som skal lagres. Fordelen med mange av disse er at du fint kan legge til nye felter i en tabell/schema/whatever uten at det lager problemer da selve poenget med disse databasene er at du skal kunne legge til ting. Det sagt, er det ofte at de ikke er på langt nær like raske som relasjonelle databaser, så det kommer veldig an på hva du skal ha det til om det i det hele tatt er aktuelt.

Normalisering av databser; https://no.wikipedia.org/wiki/Normalisering
Du kan titte på denne ang normalisering. https://www.tek.no/artikler/php-mysq...pittel-9/36329

Databasedesign kan ofte være et felt som krever "mengdetrening" for å unngå duplisering, korrupte data når endringer skjer i databasen osv. Start enkelt med å lage noen testdatabaser av diskografien til en håndfull artister. Gjerne noen som har holdt på en stund, slik at de har gitt ut en mengde plater inkl live versjoner, best of, golden years etc. Da kommer du veldig fort bort i den praktiske biten rundt databaser som kan gjøre db design til en "olympisk øvelse".