Om jag har förstått det rätt så ska man försöka undvika att ha samma data på två ställen i en db. Men är det en regel utan undantag? Jag börjar få en himla massa tabeller med relationer hit och dit och det krävs ibland en massa selectsatser, joins och annat för att få fram rätt data... känns som man skulle kunna få mycket snabbare och enklare sql-frågor om man sparade undan lite extra data i fler tabeller?
Har du samma data på flera ställen kommer du -ofelbart- att missa i uppdateringarna när du redigerar data. då får du inkonsistens i datat och problem när du skall välja saker. Kör med vyer och stored procedures, använd constrains och nycklar. Skapa bas tabeller där du sätter namn och ett id för att lättare koppla ihop värden.
eg: en tabell med t ex prodgruppID och prodgruppNamn och en tabell med produktnamn och prodgruppID med mera för att kunna gruppera saker. Du kan ju då i en combobox vid t ex registrering av nya produkter selecta från b tabellen. Då kan du lägga till nya produktgrupper väldigt enkelt :)
Säg att jag har en tabell med betyg på olika spel. Här kan man ju räkna ut ett medelvärde med en sql-fråga direkt på tabellen. Men om jag istället räknar ut medelvärdet i koden varje gång en användare betygsätter spelet och sparar det nya medelvärdet i en egen kolumn i tabellen så sparar jag ju en beräkning när medelvärdet ska hämtas. Medelvärdet finns ju så att säga redan i databasen (om än inte i klartext).
Hur skulle en duktig db-arkitekt göra då? Göra beräkningen för att slippa onödig extra data som egentligen redan finns, eller lägga till en extra kolumn och spara lite prestanda?
Jag pratar ofta och gärna om en levande kärna. Det är data som skall kunna accessas omedelbart.
När tiden går man kan dock flytta en hel del transaktionsdata till historiska sidan av en db.
Det är viktigt att normalisera rätt men också att handera denormalisering.
Så ingen regel utan undantag.
Säg att jag har en tabell med betyg på olika spel. Här kan man ju räkna ut ett medelvärde med en sql-fråga direkt på tabellen. Men om jag istället räknar ut medelvärdet i koden varje gång en användare betygsätter spelet och sparar det nya medelvärdet i en egen kolumn i tabellen så sparar jag ju en beräkning när medelvärdet ska hämtas. Medelvärdet finns ju så att säga redan i databasen (om än inte i klartext).
Hur skulle en duktig db-arkitekt göra då? Göra beräkningen för att slippa onödig extra data som egentligen redan finns, eller lägga till en extra kolumn och spara lite prestanda?
Här är det nog snarare dags att fundera på från vilket håll frekvensen är störst. Hur ofta betygsätter användare spelet och hur ofta visas värdet? Visas det i listor (isåfall blir det många beräkningar)?
Om betygen visas väldigt ofta och betygsätts inte lika ofta, så kan det vara värt att kompilera denna data, ja. Dessutom ser jag inte direkt någon anledning att behöva iterera denna data (med betygen alltså) i några andra sammanhang.
/red. Fast vänta lite nu.. om man beräknar ett average på t.ex. tio värden och sparar detta, blir det verkligen rätt nästa gång ett värde tillkommer? (Jag är lite sjuk idag, så jag orkar inte tänka)..
En annan fråga, när ska man använda vyer?
För att säga emot mig själv i detta fall, så skulle du t.ex. kunna använda en vy för att förenkla hämtning av data som innefattar beräkningar eller tabellrelationer. Om du har data i en tabell, som nästan alltid skall joinas med en annan tabell, eller där beräkningar behöver ske varje hämtning (betyg kanske?), så är en vy att föredra. Då skriver du vyn, sparar den och döper den (till t.ex. vwAllGames) och sedan kan du anropa den som en tabell; "SELECT * FROM vwAllGames WHERE GameId = @gameid".
Nä SP sparar inte det aggregerade. Det fär man stoppa in i ett fält. Visten var att köra den när det hade blivit någon förändring.
Jag utgår från att man läser mångdubbelt mot vad man förändrar.
269 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
