Bedoel je tabel-fragmentatie? Daarbij zet je delen van een tabel in kleinere aparte tabellen. Met behulp van triggers en views kun je dat prima opzetten en nee,je queries worden daar niet ingewikkelder van, daar zijn de triggers etc voor. Naar buiten toe zie je gewoon een view/tabel en de views/triggers regelen de fragmentatie. Of het voor performance helpt, ja, als je extreem belachelijk veel records hebt, tientallen/honderden miljoenen, waarbij de indexes al te traag zijn.

Ik vroeg me nog af, je stelde op een gegeven moment (teminste, dat was wat ik er van begreep) dat je met APD ook kunt sorteren op 'unieke' aanroepen van een functie, dat is een unieke combinatie van functie + argumenten, klopt dat?

@Robert, het idee dat geopperd was, was om je tabellen helemaal uit elkaar te trekken, om zo hele kleine tabellen te creeeren. Die verbind je vervolgens aan elkaar door middel van FK en PK's. Dat kan enorm snel zijn, maar heeft ook zijn nadelen, zo wordt het onderhoud een stuk lastiger, worden je queries een stuk langer en uitgebreider, en moet je voor grotere queries waarbij je meer data nodig hebt, veel verschillende tabellen bij elkaar rapen.

Ik kwam je vraag niet eerder tegen, anders had ik eerder gereageerd ;)

Mathieu: Ik zie dat je ook aanwezig was bij de case study van Webwereld en heb een vraagje. Op gegeven moment had Sander van de Graaf het over de-normalisatie i.v.m. het ophogen van het aantal views van een bepaalde foto. Hierbij kwamen er vanuit het publiek ook suggesties.

Eén van de suggesties (door iemand die rechts voorin zat) was een bepaalde opzet waarbij het nog sneller zou gaan (volgens mij met allemaal losse ID's o.i.d.), maar bij Webwereld wilden ze dat niet doen vanwege de data integriteit. Weet jij misschien wat er precies werd voorgesteld? (Vanuit mijn positie in de zaal was het niet goed te horen)