Betere code crux bij trage databases

Gepubliceerd: Vrijdag 6 november 2009

Vergeet de hardware-upgrade. Verbeterde code en gedegen tests zijn veel efficiëntere methoden om de prestaties van een database op te krikken.

Toon volledig artikel

Anonymous Coward op Vrijdag 6 November 2009 11:48

Mooie advertorial.

2 / 4

DeliciouslyImperfect op Vrijdag 6 November 2009 12:38

Okay, het is misschien geschreven vanuit een reclame oogpunt, maar er staat geen onwaar woord in en het geldt voor nagenoeg elk merk databaseserver.
Als DBA kan ik alleen maar beamen wat er staat.

4 / 4

Caesar Tjalbo op Vrijdag 6 November 2009 13:31

Ik geloof je onmiddelijk maar blijkbaar was het nodig om in het kader van "gewoon de datatoegang optimaliseren" een stukje vol ingetrapte open deuren te schrijven.

Vergeet de hardware-upgrade. Verbeterde code en gedegen tests zijn veel efficiëntere methoden om de prestaties van een database op te krikken. Alsof query-profiling en het kritisch bekijken van locks, gegevensomvang en normalisatie nieuwe zaken zijn.

Ik vermoed dat het naar binnen schuiven van snellere hardware in veel gevallen nog steeds goedkoper is dan het proces van onderzoek, optimalisatie en testen; 't is nogal afhankelijk van de situatie.

2 / 4

ArjenB op Vrijdag 6 November 2009 13:39

Het hangt een beetje af van welke knoeiboel je voorgangers hebben achtergelaten.

1 / 1

batlequeen op Vrijdag 6 November 2009 16:30

inderdaad,
echter als je de code zowiezo gaat optimaliseren/verbeteren is het een kleine moeite de query's direct mee te nemen

En stored procedures gebruiken kan ook veel schelen gezien je zo het netwerk en I/O-verkeer omlaag haalt

0 / 0

zwart-wit op Zaterdag 7 November 2009 00:31

Onderhoud valt en staat met documentatie. Arjen gaf al aan dat je vaak afhankelijk bent van de staat waarin je een database als DBA aantreft. Als gedegen documentatie ontbreekt of het is niet of hoegenaamd niet bijgewerkt, wens ik een ieder een prettige wedstrijd.

Mis eigenlijk de interactie met snelheidswinst mbt goed opgezette en bijgehouden indexen.

0 / 0

batlequeen op Zaterdag 7 November 2009 09:19

Vertel mij wat
Ik heb vaak genoeg code moeten vernieuwen als programmeur zonder dat er uberhaupt documentatie aanwezig was
Die dus erna maar gemaakt

0 / 0

ArjenB op Zaterdag 7 November 2009 10:50

Niet alleen documentatie. Als de opzet van je applicatie niet deugt kan je tegen de klippen op frunniken aan je database of snellere hardware installeren, maar kom je er alleen uit met een herontwerp.

0 / 0

Wulfy op Vrijdag 6 November 2009 14:05

Maxwell Cooter toch. Welke stagiair hebben ze op de vertaling van zijn artikelen gezet? ;)

0 / 2

KMK op Vrijdag 6 November 2009 15:51

Je grootste vriend is de slowquery.log
En vergeet die ORM queries niet na te kijken ;)

0 / 0

Anonymous Coward op Vrijdag 6 November 2009 16:48

no noobjectorientatie

0 / 0

Botterik op Vrijdag 6 November 2009 22:34

Wat je veel ziet is dat in joins een numeriek veld wordt gejoined met een text veld. En maar afvragen waarom die query niet performed. Ja, je kan ook een keer ergens een boek over lezen.

-1 / 1

zwart-wit op Zaterdag 7 November 2009 00:33

Toch knap als er een join is tussen twee data-elementen van verschillende types en er komt toch data uit je query :-)

0 / 0

brianS op Zaterdag 7 November 2009 20:06

Onvoorstelbaar dat zoveel kennis over data analyse, database ontwerp, toegangspadanalyse en optimalisatie verloren zijn gegaan in de laatste jaren.
Het betoog van Maxwell Cooter zou overbodig zijn als een degelijk basis opleiding werdt gegeven ipv flut cursussen over het gemak van joins.
Ik kwam 36 jaar geleden voor het eerst in aanraking met databases en wat gold toen geldt ook nu.
Kent iemand nog Codd? Date? Rosemary Rock Evans? of onze eigen Steve Cannan (NL vertegenwoordiger in ISO SQL)?
Waar is hun werk gebleven? Hebben we van extpertise geleerd? blijkbaar niet.
De databse engines zijn beter gewoorden maar de basis principes blijven hetzelvde. Zonder een solide fundering (data model) kan je geen huis bouwen.
Tweaking is te laat, met tweaking probeer je recht te zetten wat al fout in de fundering zat!!!!!
Databases bouwen begint met degelijk en zorgvuldig Logisch DATA ANALYSE, daarna database ontwerp (op papier) dan toegangsanayse.
Als dat allemaal gebeurt is mag een programmeur aan de gang, eerder niet.
Maar ja, analyse is waarschijnlijk gesneuveld door de crisis en er wordt geluisterd naar de snel jongens met de grootte bek en geen ervaring. Jammer.
Terug naar school aub.