Diskusjon av databaseoppsett

[havremunken]

Hadde bare noen små kommentarer / spørsmål til diagrammet på draw.io. Lager en nummerert liste så det er lettere å referere til dem. Merk at dette er like mye spørsmål for å trigge en intern diskusjon i huet mitt som spørsmål til deg. :)

1. Stadium-tabell. Vil det finnes omstendigheter hvor vi kan ønske oss å telle på en annen stadion enn Lerkendal? Det koster selvfølgelig ingenting å ha en tabell med én rad, men samtidig - vil den tilføre noe? Legger RBK noe ut på BillettService når de spiller treningskamper i Abrahallen, f.eks.? Jeg spør fordi jeg lurer, er det andre steder som kan være nyttige å telle bør vi jo ha denne.
2. Stand-tabellen; Burde vi ha ett nivå "over" denne? Tenker da på at det i BillettService-filene er delt inn i f.eks. ADR og ADRV (fra minnet, men tror det var riktig). Burde vi ha en overordnet sak som heter "Adressa" som ADR og ADRV hører inn under? Dette for å gjøre inndelingen mer intuitiv for brukerne.
3. Tribune-alias - Dette gjelder kanskje ikke så mye, men litt på samme måte som forrige punkt (kan kanskje også løses med felles tabell), er det mulig å si at vi vil ha Øvre Øst, og få de seksjonene som hører til under der? Jeg er så lite kjent med tribuneoppsettet at jeg ikke vet om dette ville være aktuelt for flere ting.
4. Super-flisespikking: I Game-tabellen er det både KickoffDate og KickoffTime. Jeg pleier å kombinere dato og tidsfelter i én Datetime-kolonne. Er det noen grunner til å ikke gjøre det? Igjen spør jeg fordi jeg lurer, jeg har aldri sett noen begrensninger med dette, men de kan jo lett være der uten at jeg er klar over dem. :)
5. Forstår jeg det rett hvis jeg leser det som at Count-tabellen blir den som inneholder massive mengder data her, i.e. en rad pr. sete som har forandret seg pr. snapshot? Isåfall, noen mulige forslag for å effektivisere (det er flisespikkeri og småtteri jeg snakker om her, men med mange rader kan det jo monne). 5.1 Vil det være nødvendig med en TicketType-tabell? Jeg ser absolutt poenget med den, og hvis det er fler applikasjoner som skal lese rett fra databasen vil dette kunne gjøre det mer dynamisk å håndtere nye "setekoder" etterhvert. Men siden det er mer enn bare ETTCode her, så tenker du antageligvis ikke 1:1-forhold mellom Count og TicketType? TicketType vil rett og slett inneholde én av hver av alle mulige kombinasjoner av ETTCode, Type, IsSeasonTicket og ev. andre relevante felter? Grunnen til det opprinnelige spørsmålet er jo at det blir mange rader i Count, og for å få ut relevante data må vi typisk kjøre en join med TicketType. På den andre siden - TicketType vil vel være liten og velindeksert, og det kan være en fordel å normalisere ut disse kombinasjonene til en ekstern tabell så vi får Count så slank som mulig, siden tyngden av dataene vel vil være der. 5.2 Trenger Count referanse til både Snapshot og Game? Burde ikke Snapshot ha referanse til Game, og Count til Snapshot? Da spaser vi noen stakkarslige bytes der også. ;) 5.3 Samme som punkt 4, men da for Snapshot-tabellen og Count*-kolonnene.

Jeg tror det var det jeg kom på i farta, dumper videre tanker, forslag o.l. her om de dukker opp, og så kan vi jo bare diskutere i friform så lenge.

[vemundo]

Gode spørsmål, jeg funderte på flere av disse tingene også når jeg laget utkastet. Mine tanker:

1. Tror ikke at det er andre steder enn Lerkendal som RBK vil selge billetter til. Det var vel mest uklart for meg der og da om:
   • Vil det være aktuelt å utvide informasjon omkring stadion, og det da blir ryddigere å ha det i en egen tabell?
   • Hva om Lerkendal endrer seg over tid, ref utbygging, endring av navn på seksjoner, osv. Da kan det kanskje være praktisk å ha en "ny" og "gammel" Lerkendal som to rader i stadion tabellen, som videre lenker til egne innslag i de andre tabellene, slik at vi enkelt skiller mellom gamle felt ØØ og nye felt ØØ f.eks. selv om de heter det samme. Men det blir jo bare spekulasjoner. Men jeg har vel aldri opplevd databaser hvor jeg har slått sammen tabeller, det går alltid andre veien etterhvert som verden endrer seg.
2. Mulig at jeg misforstår her, men tanken min med "stand" var at det skulle bety "tribune", og at vi for Lerkendal da ville ha 4 stand/tribune: Adressa, Rema, Adidas og Coop. (tror det er navnene i dag :) ). Men jeg hadde ikke tenkt på om det burde deles inn i øvre/nedre for hver tribune, eller bare samle det. Hva tenker du? Vi kan jo evt ha to nivåer, som jeg tror kanskje var det du mente (?) og at stand betyr f.eks. øvre adressa eller nedre adressa, og at hver stand har en kollonne som inneholder nivået over, eller at det er i en egen tabell mellom stand og stadium.
3. Du tenker at en tribune kan ha to navn slik at et alias også kan brukes? Jo det kunne jo være en kollonne i tribune tabellen f.eks. med aliaser? Vi vil helt sikkert oppleve også at tribuner skifter navn med sponsorendringer, så det å inkludere (gamle Byggern) f.eks. som lovlig valg i filtre er kanskje en ide? Eller var det noe annet du mente?
4. Nei tror ikke det er viktig om vi slår sammen i en kollonne eller ikke. Jeg tenkte litt på at vi sikkert ville gjøre søk hvor vi sammenligner kamper med samme starttidspunkt, men hvor dato er irrellevant. Men det er jo ikke noe problem å hente ut bare tidspunkt uansett hvordan det er lagret. Det vil vel neppe være salg av billetter til kamper som ikke har både en dato og et tidspunkt bestemt, så om vi lagrer det sammen er sikkert minst like lurt.
5. Ja, tanken er at count tabellen er den eneste med store mender data, de andre vil bare være småtteri, snapshot tabellen vil få ett innslag per telling og blir vel den nest største etterhvert.

5.1. Jeg tror TicketType tabellen vil ha kun en rad pr ETT code, altså i utgangspunktet rundt 86 rader før det sikkert kommer til flere koder over tid. Men en gitt telling bruker neppe mer enn det antallet for en enkelt kamp. De andre feltene der, seasonTicket, type, osv, tror jeg alle er entydlig definert fra ETT code. Så ideen er egentlig å gjøre den tabellen mer og mer presis etterhvert som vi lærer mer om ETT kodene. Det får da også tilbakevirkende kraft på gamle tellinger uten av vi trenger endre dataene i count tabellen. Ja, vi indekserer på Id i TicketType så det skal være lynkjapt å kjøre den joinen. Vi får se litt på hvordan queriene med count tabellen blir seende ut for å lage smarte indekser der, men det blir nok flere. Men jeg tenker at det viktige med å ha det i en egen tabell er å kunne lage et admin interface fra Web som lar oss gå inn og oppdatere toklningen av ETT kodene etterhvert som vi lærer mer og la det få effekt for alle tellinger uten å måtte endre annet en ett inslag i TicketType tabellen

5.2. Godt spørsmål, dette satt jeg også og funderte på når jeg skrev det. Hvis vi lenker fra count til snapshot og videre fra snapshot til game, så kan et gitt snapshot-tidspunkt kun gjelde for en kamp. Siden det stort sett er 2-3 kamper tilgjengelig for salg til enhver tid kan det evt bety at vi får 2-3 ganger flere innslag i snapshot tabellen, da vi sikkert kommer til å telle samtidig? Men vi trenger jo egentlig ikke samle data for mer enn neste kamp forsåvidt. Vi bør kanskje bestemme oss for akkurat det før vi velger hva som er mest hensiktsmessig i forhold til mindre total plassbruk av count tabellen, eller færre rader i snapshot tabellen.

5.3. Ja, det er kanskje like greit å slå sammen til en kollonne. Da kan en forsåvidt lure på om en trenger en egen tabell, men jeg funderte på om vi kom til å ville lagre ting som f.eks. om en snapshot var en del av de som automatisk trigges hver 30/60 min f.eks. eller en snapshot som er satt igang manuelt av noen. Kanskje også ha et felt som lagrer om en snapshot er den aller første for en gitt kamp, så en slipper kjøre aggregering på data for å finne den første, jeg vet ikke, det kan være slike ting som dukker opp når vi jobber videre med applikasjonen oppå databasen.

[havremunken]

Jeg tar noen snarveier her nå for å forsøke å overvinne min egen treghet; Databaseoppsettet blir jukset litt med på den måten at jeg i første omgang kun lagrer oppsummeringene, ikke alle setestatusene. Dette gjør noen ting enklere i forhold til å hente ut ferdig tygde data, samtidig som det reduserer fleksibiliteten på litt sikt. Jeg skal gjøre mitt beste for at dette ikke skal bli en permanent feil.

[nilsgs]

Kjører vi database og API rett opp i Azure eller?

[havremunken]

Jeg har tenkt tanken på å kjøre det i Azure etterhvert, og forsøker å skrive en del av de jobbene som drar inn datafiler o.l. sånn at de lett kan kjøres som Azure web jobs eller hva de heter. Det blir vel til slutt bare et spørsmål om hva det koster.

Inntil vi finner ut av det tenkte jeg bare å kjøre det på en gammel stakkar av en server som kjører hjemme hos meg. Win2008R2 med en SQL Server 2008 kjørende. Ikke fantastisk, men duger for å teste funksjonalitet o.l. inntil videre.

Har forøvrig funnet ut at livet er for kort, så jeg bruker Entity Framework for data-aksess. Begynte på noen repositories med litt manuell SQL, men fant fort ut at jeg ikke orket. Har laget et "lag" med interfaces mellom så ikke noe logikk trenger å berøre EF i tilfelle vi bestemmer oss for å bytte det ut etterhvert. Det bare fristet så veldig å ikke gjøre alt på gamlemåten. :)

[nilsgs]

Jeg har "gratis" (limit på 950kr/mnd) Azure igjennom MSDN noe som skal holde til det meste. Vi kan godt bruke den kontoen.

EF funker fint det. Ikke noe grunn til å komplisere unødvendig.

[havremunken]

Kult, det høres bra ut!

Bra, da skammer jeg meg ikke for EF. Ikke at jeg vet noe er feil med det, men har latt meg påvirke litt av anti-ORM-bevegelsen.

Håper å få ting litt i water her så jeg kan begynne å laste opp db-relatert kode. Er helt nybegynner på EF (har gjort noen prosjekter på NHibernate tidligere) så kan godt være forbedringspotensiale.

[vemundo]

Er det noe i veien for å kombinere med vanlig SQL her og der ved behov?

[havremunken]

Nei - bruker bare en standard connection string som like gjerne kan brukes med en "normal" kobling til SQL-bibliotekene til .Net ihvertfall. Entity Framework er jo bare et lag på toppen av dette egentlig, som lar oss mappe objekter og skrive queries rett i c# som blir oversatt til brukbar SQL - litt som Hibernate m.fler.

Ser ingen problemer med å gjøre enkelte ting i SQL hvis det er mer hensiktsmessig.

[nilsgs]

Hvordan vi henter ut dataene er noe vi kan ta etterhvert, om det blir EF, Dapper eller noe annet er ikke så viktig.