Kom ihåg mig?
Home Menu

Menu


Vad är fel i min SQL?

 
Ämnesverktyg Visningsalternativ
Oläst 2013-02-01, 10:23 #21
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Citat:
Ursprungligen postat av ConnyWesth Visa inlägg
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?
Clarence är inte uppkopplad   Svara med citatSvara med citat
Oläst 2013-02-01, 11:24 #22
danjel danjel är inte uppkopplad
Medlem
 
Reg.datum: Nov 2003
Inlägg: 214
danjel danjel är inte uppkopplad
Medlem
 
Reg.datum: Nov 2003
Inlägg: 214
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
danjel är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 09:14.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017