Hej! Jag har kommit till det stadiet att jag måste "denormalisera" en databas. Just för att speeda upp vissa sql frågor. T.ex. en fråga har jag lyckats "tune'a" ner från 1900 sekunder till 40. Men det räcker inte!
Jag hade tänkt mig att lägga resultatsettet i en och samma tabell. Jag vill ju se till att jag alltid har färskt och korrekt data i den nya tabellen. Så då använder jag cascade, men det funkade inte som jag hade tänkt mig, se exempel nedan.
Finns det nåt sätt man kan länka kolumner på annat sätt? Det handlar om en oracledatabas.
Mkt tacksam för hjälp!
create table parent
(
parent_id int not null,
parent_db_id int not null,
parent_name varchar2(20),
primary key(parrent_id,parrent_db_id)
)
create table child
(
child_id int not null,
parent_id int,
parent_db_id int,
parent_name varchar2(20),
primary key (child_id),
foreign key (parent_id,parent_db_id,parrnt_name)
references parrent(parent_id,parent_db_id,parent_name)
on delete cascade
on update cascade
)
Hur mycket data rör det sig om totalt i schemat? Kan man få se frågan?
Om du inte har miljontals rader i databasen, gär det med 99% sannolikhet att optimera SQL'n.
Kul att se en fråga om DeNormalisering, en av mina käpphästar!
Kan du skapa en "levande kärna" av de data som är viktiga.
Det låter som om du dra på mycken historik! Är det nödvändigt?
Är det inte mycket av nycklar! Var är tidsstämplarna?
Loggar in för att svara och drar mig snabbt ut igen säger Lasp, Förlåt överträdet ;-)
Välkommen till wF glömde jag ju i hastigheten ;-)
Härligt engagemang!
Index används på ett korrekt sätt. Det hämtas data, på ett ganska komplext sätt, från tretton olika tabeller. Fem av dessa har fler än 4 miljoner poster. Det som slöar ner det hela är att jag varit Tvungen till att använda en vy som joinas in.
Frågan, det var ju hur man kan hålla data uppdaterat vid en denormaliering. "On update/delete cascade" verkar ju bara fungera på nycklar. Om min tabellstruktur, queryn från post1, skulle fungera så är ju problemet löst. Finns det några andra varianter man kan använda sig av?!
jo, visst hade jag kunnat göra det.
Men min ursprungliga fråga handlade ju inte om att göra sql:en snabbare, utan om att bibehålla korrekt data vid en denormalisering.
Härligt engagemang!
Index används på ett korrekt sätt. Det hämtas data, på ett ganska komplext sätt, från tretton olika tabeller. Fem av dessa har fler än 4 miljoner poster. Det som slöar ner det hela är att jag varit Tvungen till att använda en vy som joinas in.
Frågan, det var ju hur man kan hålla data uppdaterat vid en denormaliering. "On update/delete cascade" verkar ju bara fungera på nycklar. Om min tabellstruktur, queryn från post1, skulle fungera så är ju problemet löst. Finns det några andra varianter man kan använda sig av?!
Kolla på triggers! Med hjälp av dom kan man automatisk propagera ändringar vidare till andra tabeller på ett smidigt sätt.
Men rent spontant utan att varken känna till hårdvara eller Sql-frågan verkar det som att frågan kan förbättras. Hur ser frågans execution plan ut? Dom brukar vara väldigt bra att analysera när man har prestandaproblem.
För ett tag sedan hade jag ett liknande problem fast inte med lika mycket data. Det handlade om ett sökfråga (fulltext) som sattes ihop on the fly. Databasen var normaliserad vilket ju är bra för lagring men för att söka i? Nja. Det gick otroligt långsamt trots att det fanns index på lämpliga ställen. I det fallet behövdes inget plattas till utan det gick att snabba upp frågan genom att delvis skriva om den.
132 ms totalt · 3 externa anrop · v20260731065814-full.25f56b17
