Open havremunken opened 9 years ago
Gode spørsmål, jeg funderte på flere av disse tingene også når jeg laget utkastet. Mine tanker:
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.
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.
Kjører vi database og API rett opp i Azure eller?
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. :)
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.
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.
Er det noe i veien for å kombinere med vanlig SQL her og der ved behov?
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.
Hvordan vi henter ut dataene er noe vi kan ta etterhvert, om det blir EF, Dapper eller noe annet er ikke så viktig.
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. :)
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.