Utförande av olika tillvägagångssätt för tidsbaserad data

Å ena sidan är det bra att du har öppnat en ny fråga. Men å andra sidan, genom att extrahera en fråga och fråga om den fungerar snabbare, förlorar sammanhanget för den föregående frågan, den nya frågan är alltför isolerad. Som jag är säker på att du vet är administrering av en databas, hantering av resurser (minne/cache, disk, CPU-cykler), hantering av kod (bra eller dålig) som använder dessa resurser en del av hela bilden. Prestanda är ett handelsspel, ingenting är gratis.

Det främsta problemet jag hade var dupliceringen av kolumnen EndDate, som är lätt att härleda. Duplicerade kolumner är lika med Update Anomalies. Smirkingman har gett det klassiska exemplet:vissa frågor kommer att få ett resultat och andra frågor kommer att få det andra. Det är helt enkelt inte acceptabelt för stora organisationer; eller i banker (åtminstone i utvecklade länder) där uppgifterna granskas och skyddas. Du har brutit mot en grundläggande normaliseringsregel och det finns straff att betala.
- Uppdatera Anomailes; två versioner (redan detaljerade). Revisorer får inte passera systemet.
- Tabellstorlek
  I alla stora tabeller är det ett problem, och särskilt i tidsserier eller tidsdata, där antalet kolumner är litet och antalet rader är enormt. Så vad, kommer vissa att säga, diskutrymme är billigt. Ja, det är även könssjukdomar. Det viktiga är vad det används till och hur väl man tar hand om det.
  - Diskutrymme
    Kan vara billigt på en PC, men i en produktionsserver är det inte det. I grund och botten har du lagt till 62 % till radstorleken (13 plus 8 är lika med 21) och därmed tabellstorleken. På den bank jag för närvarande är tilldelad debiteras varje avdelning som äger datan enligt följande, SAN-baserad lagring är allt som finns. Siffrorna är per GB per månad (detta är inte en högklassig australisk bank):
    
    1,05 $ för RAID5 Unmirrored
    (vi vet att den är långsam, men den är billig, lägg bara inte viktig information på den, för om den går sönder, efter att den nya disken är varm eller kall bytts in, tar det dagar för den för att återsynkronisera sig själv.)
    
    $2,10 för RAID5 Mirrored
    I SAN, alltså.
    
    $4,40 för RAID1+0
    Minimum för produktionsdata, säkerhetskopierade transaktionsloggar och nattliga databasdumpar.
    
    $9,80 för RAID1+0 replikerad
    Till en identisk SAN-layout på en annan, bombsäker plats. Produktionsavbrott på minuter; nästan noll transaktionsförlust.
  - Minne/cache
    Ok, Oracle har det inte men de seriösa banktjänsterna har cacher och de hanteras. Med tanke på någon specifik cachestorlek kommer endast 62 % av raderna att passa in i samma cachestorlek.
  - Logisk &Fysisk I/O
    Vilket innebär 50 % mer I/O för att läsa tabellen; både strömning till cache och diskläsning.
Därför är frågan om frågan fungerar bättre eller sämre isolerat en akademisk fråga. I samband med ovanstående, tabellen är långsam och presterar 62 % sämre, hela tiden, vid varje åtkomst. Och det påverkar alla andra användare på servern. De flesta DBA:er kommer inte att bry sig (jag skulle absolut inte göra det) om subquery-formuläret fungerar med halva hastigheten, eftersom deras bonus är knuten till revisionsacceptans, inte bara kodprestanda.
- Dessutom finns det den extra fördelen att aldrig behöva gå igenom koden igen och åtgärda transaktioner på grund av uppdateringsavvikelser.
- Och transaktionerna har färre poäng att uppdatera, så de är mindre; mindre blockerande lås etc.
Håller med, den diskussionen i kommentarerna är svår. I mitt svar har jag detaljerat och förklarat två underfrågor. Det uppstod ett missförstånd:du pratade om den här underfrågan (i WHERE-satsen, en tabellunderfråga ) och jag pratade om den andra underfrågan (i kolumnlistan, en skalär underfråga ) när jag sa att det fungerar lika snabbt eller snabbare. Nu när det har klarats upp kan jag inte säga att den första frågan ovan (underfrågan i WHERE-satsen, en tabell) kommer att fungera lika snabbt som den andra frågan (med den duplicerade kolumnen); den första måste utföra 3 skanningar, där den andra endast utför 2 skanningar. (Jag vågar påstå att den andra kommer att skanna tabellen dock.)

Poängen är att förutom isoleringsfrågan är det inte en rättvis jämförelse, jag gjorde kommentaren om skalära subqueries. Jag skulle inte föreslå att en 3-skanningsfråga är lika snabb eller snabbare än en 2-skanningsfråga.

Uttalandet jag gjorde om tabellunderfrågan med 3 skanningar (som jag citerar här) måste tas i hela sammanhanget (antingen det inlägget i toto eller ovanstående). Jag backar inte från det.

Jag tillbringar halva mitt liv med att ta bort olagliga alternativ som duplicerade kolumner, som bygger på frågan om prestanda, där skaparna skanderar mantrat att tabellen är långsam, så de har "avnormaliserats för prestanda". Resultatet, förutsägbart innan jag börjar, är ett halvt så stort bord som presterar dubbelt så snabbt totalt . The Times Series är den vanligaste frågan här (länken länkar till en annan fråga; vilken länkar till en annan), men föreställ dig problemet i en bankdatabas:daglig OpeningExposure och ClosingExposure enligt Security per Holding per UnitTrust perPortfolio .
Men låt mig svara på en fråga som inte har ställts. Denna typ av interaktion är normal, inte ovanlig när man arbetar med interna utvecklingsteam; det kommer upp minst en gång i månaden. En kraschhet utvecklare har redan skrivit och testat sin kod, med hjälp av en tabell med en duplicerad kolumn, den flyger, och nu har den stannat eftersom jag inte kommer att lägga den i db.

Nej, jag kommer att testa det inom ramen för hela systemet och:
- halva tiden går tabellen in utan EndDate-kolumnen eftersom det inte är så stor sak att en halv sekunds fråga nu fungerar på en sekund.
- Den andra hälften av tiden är prestanda för [tabellunderfrågan] inte acceptabel, så jag implementerar en boolesk (bit)-indikator för att identifiera IsCurrent . Det är mycket bättre än en duplicerad kolumn och ger 2-skanningshastigheter.
- Inte om en miljon år kommer du få mig att duplicera en kolumn; lägga till 62 % till tabellstorleken; saktar ner tabellen i hela fleranvändarsammanhanget med 62%; och riskerar att misslyckas med en revision. Och jag är inte anställd, jag får ingen bonus.
Nu skulle det vara värt att testa:fråga med en duplicerad kolumn kontra fråga med en IsCurrent indikator, i hela sammanhanget för den övergripande resursanvändningen.
Smirkingman har tagit upp en bra poäng. Och jag kommer att återge det tydligt, så att det inte blir fragmenterat och sedan blir det ena eller andra fragmentet attackerat. Vänligen bryt inte upp detta:

En relationsdatabas,
normaliserad av en erfaren relationsmodeller, till sann femte normalform
(inga uppdateringsavvikelser; inga duplicerade kolumner),
med fullständig efterlevnad av relationer
(IDEF1X, särskilt relaterat till minimering av Id Primära nycklar; och därmed inte förlama kraften i den relationella motorn)
kommer att resultera i fler, mindre tabeller, en mindre databas,
med färre index,
kräver färre kopplingar
(det stämmer, fler tabeller men färre anslutningar),
och det kommer att prestera bättre än allt som bryter mot någon av dessa regler
på samma hårdvara och företag db-plattform
(exkluderar gratisprogram, MS, Oracle; men låt det inte stoppa dig),
i det fullständiga sammanhanget för produktion av OLTP-användning
med minst en storleksordning,
och det blir mycket lättare att använda
och att ändra
(behöver aldrig "refactoring").

Jag har gjort detta minst 80 gånger. Två storleksordningar är inte ovanliga, om jag gör det själv, snarare än att ge ramarna för någon annan att göra det.

Varken jag, inte de jag arbetar med eller som betalar mig, bryr mig om vad en fråga kommer att göra isolerat.