[Clarence]

Ursprungligen postat av ConnyWesth

Den lösningen bryter mot en av relationsdatabasteorins grundregler, nämligen redundansproblmatiken. Redundans skapar kvalitetsproblem på själva datat och ska därför undvikas till varje pris.

Min lösning löser trådskaparens problem, och gör det på ett effektivt, enkelt, lättfattligt, underhållsvänligt och tryggt sätt. Sen får trådskaparen välja själv.

Denormalisering är den enklaste och i särklass mest effektiva lösningen för att lösa många prestanda-problem som kommer av normaliserad välstrukturerad data. Vill du läsa mer om detta etablerade och välanvända koncept kan du börja här: http://en.wikipedia.org/wiki/Denormalization

Just p g a av att läslasten är så mycket högre än skrivlasten blir det ett väldigt effektivt verktyg. På ett forum kan du räkna med en ratio på iaf 100:1, även om det oftare hamnar närmare 1000:1.

Om du inte vet vad det innebär att läsa resultatet från en EXPLAIN på din query så har du inte en aning om din lösning faktiskt är effektiv efter MySQLs query plan. Om du kör den och läser på om betydelsen av resultatet så kan du lätt inse att din query är väldigt ineffektiv.

[Conny Westh]

Ursprungligen postat av Clarence

Denormalisering är den enklaste och i särklass mest effektiva lösningen för att lösa många prestanda-problem som kommer av normaliserad välstrukturerad data. Vill du läsa mer om detta etablerade och välanvända koncept kan du börja här: http://en.wikipedia.org/wiki/Denormalization

Just p g a av att läslasten är så mycket högre än skrivlasten blir det ett väldigt effektivt verktyg. På ett forum kan du räkna med en ratio på iaf 100:1, även om det oftare hamnar närmare 1000:1.

Om du inte vet vad det innebär att läsa resultatet från en EXPLAIN på din query så har du inte en aning om din lösning faktiskt är effektiv efter MySQLs query plan. Om du kör den och läser på om betydelsen av resultatet så kan du lätt inse att din query är väldigt ineffektiv.

För att det över huvud taget ska vara intressant att diskutera denormalisering eller optimering som strider mot de grundläggande principerna för hur man bygger relationsdatabaser (exempelvis normalisering för unvikande av redundans) så måste man göra en kalkyl på vad den eventuella vinsten kan bli vid en genosnittlig belastning, i jämförelse med den tid det tar att utveckla denna förändring i form av mantid och kostnader. För att en optimering ska vara intressant så måste minst fyra minimikriterier vara uppfyllda (ibland behöver fler kritrier vara uppfyllda):

1 - Garanterad datakvalitet
2 - Det ska verkligen finnas ett upplevt behov dvs det måste föreligga ett kännbart prestandaproblem
3 - Den beräknade prestandavinsten ska vara avsevärd
4 - Kostnaden måste stå i rimlig proportion till den tidsvinst man beräknas göra

Jag ger mig aldrig in på optimering ur prestandasynpunkt om det inte finns ett verkligt behov av det, dvs om det är någon som upplever att systemet tar för lång tid att köra. Annars är det rent slöseri med arbetstid.

[tartareandesire]

Ursprungligen postat av ConnyWesth

Jag ger mig aldrig in på optimering ur prestandasynpunkt om det inte finns ett verkligt behov av det, dvs om det är någon som upplever att systemet tar för lång tid att köra. Annars är det rent slöseri med arbetstid.

Då tänker du helt galet. Många system som myndigheter och andra stora organisationer använt sig utav har kollapsat efter ett antal år just eftersom man inte tänkt efter redan från början. Drift kostar i längden mer än utvecklingstiden vid ett tillfälle och optimering i efterhand är mycket mer tidsödande och komplicerad än om den görs redan från början. I det här exemplet tar det inte heller ens längre tid som du påstår, det gäller bara att veta vad man gör.

Att utveckla resurssnåla system ligger dessutom på allas ansvar. Även inom webb- och systemutveckling bör man vara miljömedveten. Naturligtvis kan man inte fördenskull bygga svårtolkade system som saknar all form av logik men i just det här exemplet så är det bara rent löjligt att vara så pass stelbent bara för att man är rädd att bryta mot en obsolet regel som man hakat upp sig på.

[Conny Westh]

Ursprungligen postat av tartareandesire

Då tänker du helt galet. Många system som myndigheter och andra stora organisationer använt sig utav har kollapsat efter ett antal år just eftersom man inte tänkt efter redan från början. Drift kostar i längden mer än utvecklingstiden vid ett tillfälle och optimering i efterhand är mycket mer tidsödande och komplicerad än om den görs redan från början. I det här exemplet tar det inte heller ens längre tid som du påstår, det gäller bara att veta vad man gör.

Att utveckla resurssnåla system ligger dessutom på allas ansvar. Även inom webb- och systemutveckling bör man vara miljömedveten. Naturligtvis kan man inte fördenskull bygga svårtolkade system som saknar all form av logik men i just det här exemplet så är det bara rent löjligt att vara så pass stelbent bara för att man är rädd att bryta mot en obsolet regel som man hakat upp sig på.

Du får gärna visa på hur koden skulle se ut om du optimerrar enligt dina principer.

Jag tycker dock inte att normalisering av relationsdatabaser är obsolete.

Jag har fokuserat på att göra koden enkel och lätt att förstå, så just underhållskostnaden ska bli så låg som möjligt.

Det är fritt fram för den som önskar att visa på de prestandavinster som uppnås vid en optimering ur prestandasynpunkt. Det vore i högsta grad intressant att se.

Jag har bidragit med grundstommen till detta, så någon annan får gärna bidra med det denne anser vara relevant. Gärna med prestandamätningar. M a o bevisa gärna att jag har helt fel.... Då lär jag mig något nytt så dagen är inte förlorad för det...

[Clarence]

Ursprungligen postat av ConnyWesth

Du får gärna visa på hur koden skulle se ut om du optimerrar enligt dina principer.

Jag tycker dock inte att normalisering av relationsdatabaser är obsolete.

Jag har fokuserat på att göra koden enkel och lätt att förstå, så just underhållskostnaden ska bli så låg som möjligt.

Det är fritt fram för den som önskar att visa på de prestandavinster som uppnås vid en optimering ur prestandasynpunkt. Det vore i högsta grad intressant att se.

Jag har bidragit med grundstommen till detta, så någon annan får gärna bidra med det denne anser vara relevant. Gärna med prestandamätningar. M a o bevisa gärna att jag har helt fel.... Då lär jag mig något nytt så dagen är inte förlorad för det...

Det borde vara tämligen uppenbart att resultatet är vad det är. Men för att vidare illustrera det så la jag in 400 000 poster med random data - lite knappt vad WN har.

Resultatet:

Hämta senaste tråden enligt createddate (detta är synonymt ur prestandasynpunkt med ett extra fält såsom Westman klokt föreslog):
11,4ms exekveringstid

Köra din groteska UNION subquery:
1560ms exekveringstid (eller 4000+ ms med kall bufferpool, från ssd)

Fyller du en sajt med sådana queries för att sedan få lite bra reklam i något populärt medie ... då går din sajt ner när den skulle ha nått sin höjdpunkt. Och du kommer inte hinna åtgärda det innan din peak är borta och all din framgång för denna gång förlorad. Bad luck or bad choices?

[danjel]

En mycket bra tråd ur lärosynpunkt.
Generellt kring databasfrågor och normalisering,
man bör även skilja på prestanda och skalbarhet.

Bara för att en funktion X går långsammare än funktion Y på liten datamängd , säg några tusen rader, så är inte Y bättre.
Ett exempel att man kan dela upp en sql i flera olika frågor och t.ex göra sorteringar och sammanslagningar i php istället för sql. Det kan ofta ta lite längre tid när man mäter prestanda, men är mer skalbart och snabbare när datamängd ökar.
Ett sådant angreppsätt kan belasta php/webbserver mer än db server men det är ju betydligt enklare att skala upp webbservern(a).
Dessutom brukar det vara enklare att underhålla och förstå sådan kod, åtminstone för webbutvecklare som inte har DBA kompetens