Hvordan lage en webside med database som er oversiktig & spesifisert

[Lanko]

fra e.eks. exel.

 

skal ikke se slik ut:

 

men bør ha mulighet til å velge mer spesifisert,

Endret 19. november 2014 av MR. H-W

[Crowly]

Man trenger kunnskap innen html, css, sql og ett server side språk som f.eks. php, java, asp o.l. Avhengig av funksjonaliteten på siden bør man kunne noe om javascript også.

 

Å hente ut data fra en database og presentere det i en tabell slik du har gjort er en ganske smal sak. Men du gir veldig lite informasjon om hvordan dette skal fungere og hva det skal brukes til. Uten flere detaljer er det vanskelig å si noe veldig spesifikt.

[RulleRimfrost]

Om man ikke har noe erfaring med html / css / JS, så kan det være en ide å bare hoppe rett på et drag and drop IDE. F eks kan man hente MS sitt gratis. Het Visual Web Developer e.l. sist jeg brukte det. Ca halvparten av tutorialene går ut på noe lignende det som er beskrevet.

Med en manuell løsning vil men bruke mye tid på å knote design, mens i et d&d IDE vil man bruke tilsvarende mye tid på å debug og leting etter innstillinger (IDE-kode blir ca 17 ganger mer komplisert enn nødvendig)

[quantum]

Kanskje lurt å tenke på spesifikasjon først og deretter hvordan problemet løses. En begynnelse kunne jo være å forklare hva dette er for noe/skal brukes til, og det er jo forsåvidt en del av spørsmålet også.

 

En vanlig måte å spesifisere på er å skrive brukerhistorier. En brukerhistorie er en slags beskrivelse av en overordnet funksjon på formen Hvem i hvilken rolle gjør hva slik at et eller annet konkret oppnås:

 

Eks: Som en vanlig spiller logger jeg inn på fotballklubbens nettsider og bestiller klubbavisa i profilen min slik at den blir sendt meg på epostadressen i profilen hver uke.

 

Vanligvis består en spec av mange mange slike brukerhistorier, og her kan man finne hint om hva databasen skal inneholde. Utifra ovenforstående skjønner vi at vi må ha en bruker med profil, og hvis det ikke kommer flere krav til profilen kan dette kanskje løses med en tabell med brukernanv, kryptert passord, epost og kolonne som viser om nyhetsbrev er ønsket. Formelt kan man spesifisere databasen i form av ulike datamodelldiagrammer, f.eks. Entity Relationship.

 

I tillegg kommer en masse andre krav fra omgivelsene, antall brukere, plattform, integrasjon med andre systemer, time to market osv. osv. og atter osv. som blir avgjørende for resten av spesifikasjonen.

 

Det vanskeligste med spesifikasjon er å innse at den foreldes raskt, derfor er det ofte bortkastet med detaljert spesifikasjon av annet enn det som skal implementeres i nær fremtid.

 

Her aner vi ingenting om hvem som skal bruke dette til hva, eller noe som helst, så det er ikke mulig å gi noen særlige råd, egentlig. Det eneste jeg kan si utifra det skisserte regnearket er at det ikke egner seg i en database uten å omstruktureres litt. Kort forklart fungerer databaser slik at man definerer kolonnene "en gang for alle" (dvs. inntil nye krav oppstår), og så oppdaterer, redigerer eller sletter man radene. Her må man legge til en kolonne hver gang en ny person blir med i prosjektet, eller hva dette er for noe. Det er fullt mulig å gjøre, men ikke ønskelig, og den mest opplagte grunnen er at systemet/systemene som bruker databasen også må oppdateres når man endrer kolonner, og da blir det plutselig veldig, veldig tungvint å legge til en bruker/medlem/prosjektdeltager/whatever. Ett skritt i riktig retning her kunne være å ha faser som kolonner og personer som rader isteden. Hvis det er aktuelt å legge til flere faser også må man nok til med flere tabeller.

 

Sum-rader/kolonner definerer man ikke i tabellen, men regner isteden ut "on the fly", enten med SQL-funksjonen sum() eller i programmet som leser fra tabellen.

 

Presentasjonen på nettsiden kan godt se slik ut som på skissen, hvis ønskelig. Det er faktisk ganske sjelden det du ser på skjermen i et eller annet tabellformat er hentet direkte ut av én tabell. Databasen vil alltid gi deg resultatet av en spørring i tabellformat, men det kan være sammensatt av data fra flere tabeller (SQL JOIN), eventuelt kan systemet som bruker databasen gjøre flere spørringer mot enkelttabeller og slå sammen resultatet selv på ønsket vis.

Endret 22. november 2014 av quantum