Hjälp strukturera budgetapplikation C#

[
   {
      "date":"2022-08-11",
      "category":"Utgift:Prenumeration:Google",
      "vendor":"Google Inc",
      "amount":"-262,37",
      "comment":"Årsavgift Google Drive."
   }
]

Du behöver Id, kategorierna kan vara en egen enum med id för att lättare hålla koll på och sortera eller ännu hellre bryt ut typ av utgift och tjänst. Summan behöver räcker det med att kolla av mot en utgift/inkomst prop om det ska gå på minus eller plus om du behöver det. Tror du behöver göra en ritning över databasstrukturen och vad dina modeller faktiskt behöver för att appen ska funka bra.

Om syftet är att doppa tårna i något du kanske kommer jobba med i framtiden är excel-export absolut bra. Internt en databas dock, SQL funkar ju men det är ingen som gör det manuellt längre så då är det väl bättre att försöka fatta EF eller liknande ORM. Eller så kör du på något mer "hett" som MongoDB eller så, vilket inte matchar perfekt för ditt användningsområde men som används väldigt mycket "ute i verkligheten". Är tanken att jobba med liknande saker, alltså typ affärsapplikationer eller så, så är det ju web som gäller idag. Varför inte försöka på att bygga en micro-service-applikation i Kubernetes eller Docker med ett webbgränssnitt?

Det kan vara färgat av att det är vad jag jobbar med, men det verkar också vara standard bland alla företag som tjatar om att rekrytera mig nästan oavsett vad de pysslar med, och även bland mina bekanta, före detta kollegor och så.

Tja, man får ju fundera på funktionen databasen ska användas för förstås, men för många saker är dokumentbaserad NoSQL en bättre fit än SQL. Applikationen jag jobbar med exempelvis använder Mongo i alla utom en service men även den ska ju över dit inom kort. Dock kommer vi ändå behöva en SQL-instans för en tredjepartsprodukt som vi inte verkar kunna få bort, och vars ägare drar fötterna efter sig med att komma in i 2000-talet, inte så mycket på grund av databasvalet specifikt utan i allmänhet.

Hur mycket det används i verkligheten är förstås svårt att svara på. Jag läser inte jobbannonser i någon större utsträckning men jag har rekryterare som hör av sig hela tiden och i vad de skickar så är Mongo väldigt vanligt, SQL också visserligen. Men på min LinkedIn (vilket är vägen rekryterare hittar mig) så står det att jag har stora kunskaper inom SQL (vilket är helt sant) men Mongo nämns inte för jag har inte uppdaterat min LinkedIn på ganska länge då jag inte letar nytt jobb, ändå är de förfrågningar jag får ungefär likvärdigt fördelade mellan dem.

Samtidigt är ju databaser rätt bortabstraherade idag i allmänhet. Jag skapade en ny service till vår produkt förra veckan exempelvis och jag rörde inte, eller ens tittade på, databasen förrän jag var "klar" med CRUD-grejer och testade. Jag använde ett internt och helt generellt nuget-paket så allt jag behövde göra i min service var att lägga till en specifik dbcontext med en handfull rader kod så genererades allt åt mig inklusive index och så. Hade det varit SQL så hade det ju varit ungefär samma effort och ungefär samma saker jag hade behövt göra.

Förlåt, jag skulle sagt; "..ingen som gör det manuellt längre i en applikation byggd detta årtusende..."

Jag jobbade typ så på mitt förra jobb också, all logik i databasen, manuellt skriven, och en hel del äldre kollegor som var misstänksamma mot allt som börjar närma sig modernt (inte bara tekniker utan också allt "agilt", code reviews och så vidare), men även de behövde ju komma in i nutiden så när jag jobbade där påbörjade de en helt ny applikation hostad i molnet med moderna tekniker och så. Det fanns förstås ett antal olika saker som motiverade det, men förutom tekniska aspekter så handlade det ju också om att kunna locka till sig, och behålla, utvecklare.

Jag säger inte att det nödvändigtvis är fel att satsa på något gammalt, men SQL är inte så gammalt att det är eftertraktat och ger bra betalt nu, då är det bättre att satsa på Cobol eller liknande. Jag vet inte om SQL kommer att bli en sådan efterfrågad kompetens om tio år eller så när de som byggde systemen gått i pension eller blivit chefer, men som jag ser det är det mindre sannolikt än dagens gamla men välbetalda skit. Cobol är exempelvis efterfrågat idag för att många gamla men kritiska system är beroende av det i delar som ingen vill (eller kan eller vågar) göra om, många gamla banksystem och så men också system för industriell produktion och liknande. SQL kan förstås finnas i massvis av gamla system, men det är normalt inte samma problem att byta ut det eller modernisera.

Angående hur populärt MongoDB är så redogör jag bara för mina erfarenheter och de säger mig att det är eftertraktat och används mycket. Det är förstås bara min uppfattning dock, men kollar man på exempelvis Stack Overflow's årliga utvecklarundersökning så ligger det hyfsat högt där också.

Cosmos DB är absolut intressant, men innebär inlåsning till Azure således går det bort för oss.

Angående databaser så finns det plats för flera.
Vi har MSSQL som bas, men använder Cosmos DB eller Mongo DB (Atlas) eller Elasticsearch) när det finns behov.

Och vi har flera applikationer som använder både Dapper och EF i samma app.
Dapper fungerar perfekt då vi behöver stöd for flera typer av databaser (DB2, Oracle, MSSQL,..) i samma applikation.

Men från ett applikations/solution arkitekt perspektiv, så föredrar vi EF (Entity Framework) då vi ser att TCO (total cost of ownership) är lägre för system som använder EF.
Vi har också sett att EF blir bättre för varje version och många gånger är bättre än en att försöka att skapa en egen ORM/repository.

Ang. EF.
Som nackdel så krävs det att utvecklare förstår hur EF fungerar. Annars kan det bli helt fel, även om det blivit mycket bättre i senare versioner av EF. (Note: logga ut alla SQL kommandon och se vad som faktiskt görs).

Oavsett om du använder EF, ADO.NET, MongoDB etc., så måste du fortfarande sätta rätt index, 'isolation', partition, och hints för hög-presterande system.

Jag känner absolut igen mig. På mitt förra jobb fanns det en hel del "dynamisk SQL" som kördes i SP's och så, alltså SQL i en VARCHAR-variabel som kördes "från" SQL. Det var ett sätt att få in variabler på ställen där SQL normalt inte stöder det, som tabellnamn i en SP, men de använde också det för att öka motståndskraften mot SQL injection, men för mig kändes det sjukt gammaldags och det tog ju bort mycket möjligheter som debugging eller execution plans för de "dynamiska" bitarna.

Men den applikationen var byggd på gammal skit som sagt. Jag genomförde en del förbättringar genom att byta ut extremt invecklade saker till "nymodigheter" som kom i SQL 2002 eller liknande. Exempelvis en cursor i en cursor i en cursor som jag bytte ut till en setbased operation och fick ner en del av en nattkörning från flera timmar till några minuter. Ögonen ramlade nästan ur skallen på mina 60+ kollegor som började med hålkort liksom.

Jo men det beror mycket på vad man bygger för något. Även om vi använder Azure mycket och vill hosta där så vill många av våra kunder ha en lokal installation exempelvis, således räcker det inte att det finns en möjlighet att byta ut det utan vi behöver en lösning som fungerar både lokalt och i "molnet".

Jag vet inte, min erfarenhet av lärarna på sådana här utbildningar, och kanske än mer på universitetet, är att de inte riktigt hänger med i branschens trender. Vilket inte är så konstigt kanske med tanke på hur fort det går, men det är väl därför många utbildningar försöker hålla det på en mer abstrakt nivå. Kollar man exempelvis på de uppgifter folk ber om hjälp med här så är de ungefär samma som när jag pluggade för femton år sedan eller så, vilket inte är så konstigt då det ju handlar om grunderna men samtidigt pratade man ju om Micro Services redan när jag pluggade men det verkar inte ha kommit in i de vanliga kurserna ännu.

Tja, det finns förstås mängder av gamla system folk jobbar med, så att det finns mycket SQL "där ute" är väl givet. Men poängen jag försöker få fram är att den stora trenden inom databaser oavsett om det handlar om skrivbordsapplikationer, webb, webservice, micro services eller vad som, och avsett om det är relationsdatabaser eller dokumentbaserade, är att databasen är i princip bortabstraherad. Är det väldigt höga krav på prestanda så kan det förstås vara värt att kolla på vad som körs och försöka optimera mer än vad ens ORM eller liknande klarar av, men det är allt mer sällan det blir bättre så ROI är ju sällan så hög liksom.

Jo så är det absolut. Men de flesta tycker inte databasutveckling är så himla kul oavsett teknik, och eftersom det sällan behövs längre så tror jag de flesta är rätt nöjda med att kunna bara generera upp en databas och inte behöva tänka på det, utan istället fokusera på koden där "magin" skapas liksom.

Jo EF är grymt, att skriva en egen ORM känns onödigt i nästan alla fall, undantaget är väl om man behöver något väldigt light weight eller väldigt specifikt. Samtidigt passar ju en dokumentbaserad DB ganska bra till objektorienterad kod med interfaces och klasser. Ens objekt motsvaras av ett dokument liksom, inte ett gäng tabeller med mer eller mindre komplexa relationer, även om det förstås finns ett mått av det även i dem.

Ja ok. Det är lite värre kanske. Samtidigt hör det väl till yrket att vilja hoppa på nya grejer liksom? Mer luttrad/erfaren kanske inte är lika snabb som någon nyexad men vill man jobba med samma saker på samma sätt utan att lära sig något nytt så är det fel yrke liksom.

Tja så kan man förstås resonera. MS med flera har ju känt konkurrensen från NoSQL och förbättrat sig på flera områden, exempelvis stöd för linux vilket ofta är ett krav idag, och försök till att förbättra skalbarheten. Mongo är inte förskonad heller, snarare har dess generalitet börjat bli en nackdel nu, istället satsar man mer på specialiserade databaser för specifika syften.

Men ur ett utvecklarperspektiv så gillar jag i alla fall Mongo eller dokumentbaserade databaser ganska kraftigt. De motsvarar ju objektstrukturen i koden liksom vilket gör det väldigt mycket enklare strukturerat, från mitt perspektiv. Har jag en klass 'Customer' som har en eller flera telefonnummer, adresser, bilar, kvitton eller vad det nu kan vara så ligger de så i Mongo och jag får ju tillbaka dem direkt därifrån, medan jag i SQL hade behövt joina och/eller uppdatera ett antal tabeller. Jag slipper i förväg fundera på om en 'Customer' kan ha flera adresser exempelvis. Behöver jag lägga till något nytt fält, exempelvis 'Title' för en viss marknad, så kan jag bara göra det på Customers från den marknaden och ignorera den annars. Utan någon downtime eller påverkan på prestanda.

Jag har inte kollat så mycket på Cosmos, dels för att det är låst till Azure men också för att det oundvikligen kostar pengar. Mongo är bara att installera och köra. Men vad jag förstår så är det väl liknande funktionalitet men kanske bättre integration mot MS andra saker och så, framför allt molntjänster.