Vid ett par tusen bör det inte ge några problem, men det är inte effektivt. Din första lösning med denormalisering är desto effektivare. Nosnajs query är enklaste och effektivaste sättet att uppdatera den. Men om man har väldigt många rader är det prestandamässigt bättre att dela upp den i X queries med ranges (ej en för varje brand) och köra dem med liten tidsintervall emellan.

Att spara denormaliserad data gör inte att man inte sparar och får nästan all nytta av normaliserade datan. Den stora nackdelen du får är att uppdatera den denormaliserade datan manuellt vilket ger en liten liten overhead vid skrivning. Att inte spara denormaliserad data ger däremot i många fall, liksom ditt, en rejäl overhead vid läsning. Skapar man en vy får man allt för ofta ännu mer overhead vid varje skrivning om den cachas då hela vyn invalideras med skrivning till någon tabell den beror på. Alternativt cachas inget och du får rejält med overhead vid varje läsning då du får läsa mer data, oavsett hur väl din indexering är genomgången.

I ditt fall går säkerligen din lösning bra - men jag ville ändå inflika med detta då jag tyckte din första lösning var rätt väg att gå.

Isolera/samla kunskap om systemet eller verksamheten
Vyer och för den delen SPn är mycket praktiska att använda om man vill ändra innehållet utan att ändra gränssnittet mot sin applikation.

Har man en vy som heter "topsales_view" så kan man skriva:

Men man kan när som helst förfina hur detta räknas ut och hur det sorteras redan i vyn. Detta utan att någon applikation som använder vyn behöver uppdateras.

Helt enkelt göra det enklare för utvecklaren!

Dölja komplexitet=mindre buggar
Ett annat användningsområde är om man har komplexa frågor som man anropar på flera ställen i sina applikationer, eller från flera applikationer så kan man samla komplexiteten i vyn och dölja den för applikationsutvecklaren, vilket minskar risken för buggar.

Prestanda
Prestandamässigt är både vyer och SPn generellt snabbare än dynamisk SQL eftersom frågorna förkompileras när man skapar sina vyer, SPn och de optimeras därmed av SQL-compilatorn.

Behörigheter
Man kan även styra behörigheter genom att endast tillåta att vissa applikationer enbart får komma åt att läsa (SELECT) på vissa vyer eller SPn och spärra direktåtkomst till övriga fysiska tabeller.

Enklare felsökning
Eftersom alla verksamhetsregler kan samlas på ett ställe som fysiskt ligger nära datat, så blir det enklare att hitta fel och åtgärda dem utan att kompilera om och distribuera ut updaterad applikationsprogramvara.

Renare och tydligare gränssnitt gentemot applikationerna

Varför har du med ett AS i subqueryn men inte i queryn?

Eller så får du fler problem och jobbigare felsökning eftersom logiken finns även i datalagret.

Det bara blev så... Jag var inte så noga då det bara är en query om ska köras EN gång.

Men vad är det för skillnad? Jag får exakt samma resultat om jag kör AS i queryn också.

Det var just det som var min poäng - AS bör vara helt irrelevant och det går lika bra utan men du har med det på ett ställe och inte på det andra. Det är bra att vara enhetlig för att slippa skumma problem.

Absolut. Tack :)

Tvärtom så får man enklare felsökning om man lägger affärsreglerna så nära datat som möjligt, då finns reglerna bara på ett ställe istället för att man ska lägga dem i varje klientapplikation man utvecklar.