★Nieuw★ een nieuwsbrief

Beste relatie,

Waarschijnlijk hebben wij ooit samengewerkt om een SQL Server-toepassing te ontwikkelen, te beheren of te verbeteren. Misschien is het vrij lang geleden dat we contact hadden, en toestemming om op deze wijze je mailadres te gebruiken heb ik nooit gevraagd.

Een paar keer per jaar zal ik een nieuwsbrief sturen waarin ik vanuit mijn praktijk iets vertel over het goed gebruik van SQL Server en natuurlijk over mijn diensten. Wil je de nieuwsbrieven niet ontvangen, laat het me weten.

Met hartelijke groet,

Paul van Oordt

Lessen uit 200+ toepassingen

In de afgelopen 20 jaar heb ik met meer dan 200 SQL Server toepassingen gewerkt. Dit zijn een paar van de lessen die ik graag met je deel.

Inadequate code is de grootste performance killer

En dit is alleen blijvend en schaalbaar op te lossen door de code te verbeteren. Er zijn heel veel manieren om het fout te doen. Een uitgebreide toelichting vind je op mijn site: wat te weten over SQL Server performance en aanbevelingen voor SQL Server ontwikkeling. Belangrijkste take away: Leer set-based te denken en te programmeren en wees op hoogte van wat kan in SQL Server.

Door een gebrek aan kennis wordt nogal eens gewerkt met inefficiënte querytechnieken. Vaak zie ik ook een suboptimale taakverdeling waarbij de applicatie taken verricht die makkelijker en beter schaalbaar in SQL Server gedaan worden. Ook komt het voor dat functionaliteit wordt gebouwd die al standaard beschikbaar is, bijvoorbeeld met betrekking tot concurrency (transaction en locking), redundantie (indexed views) of het doorzetten van data naar andere systemen (transactionele replicatie).

Performance is een ontwikkelaars-verantwoordelijkheid

Beheerders zorgen voor het platform en ze monitoren de performance. Maar zij zijn niet het beste toegerust om te tunen. Code kunnen ze niet wijzigen en dat is vaak de belangrijkste oorzaak van performance-problemen. De DBA kan indexen toevoegen, maar doet dat niet beter dan SQL Server dat automatisch kan. En dat is niet goed genoeg. Het is de ontwikkelaar die weet hoe vaak en hoeveel data wordt opgehaald of aangepast, hoe dat in de loop van de tijd gaat veranderen, en die een schaalbare manier kan bepalen om dat te doen. Performance en scalability zijn essentiële, zij het vaak vergeten onderdelen van ontwikkeling.

Hou het simpel

Ik heb veel systemen gezien die nodeloos complex zijn. Scaling out, redundantie of het inschakelen van heel andere technologieën (SQL Server Analysis Services, NoSQL, FileMaker), het wordt vaak gedaan met het oog op performance, maar zonder dat eerst de mogelijkheden van SQL Server zelf goed onderzocht zijn. Voor denormalisatie geldt: Gebruik het hele arsenaal aan indexes, indexed views en persisted computed columns. En verder: Niet doen.

Hetzelfde geldt voor voorbarige scaling out. Soms is scaling out naar een ander platform nodig, maar wat er bij komt kijken om de data up to date te houden mag niet onderschat worden. Zeker als de data ook nog getransformeerd wordt naar bijvoorbeeld een datawarehouse. Replicatie, read-only servers, datawarehouses, Analysis Services, het is geweldige technologie, maar gebruik het alleen indien echt nodig, indien de mogelijkheden van één SQL Server die alle taken verricht zijn uitgeput.

Zorg voor adequate availability en disaster recovery

Regelmatig kom ik toepassingen tegen die ontoereikend zijn wat betreft recovery point of recovery time. Iedere database die niet-reproduceerbare data bevat, verdient een point in time configuratie en backuproutine. Daarnaast is ten behoeve van hoge beschikbaarheid een basic availability group meestal in te richten zonder extra SQL Server licentiekosten. En anders kan op zijn minst een noodprocedure worden voorbereid, getest en gedocumenteerd, bijvoorbeeld door het inrichten van een lege SQL Server (geen licentie benodigd) waarop alle server level objecten zoals logins en jobs al zijn aangemaakt.

Van problemen oplossen naar problemen vermijden

In de afgelopen jaren heb ik honderden SQL Server-implementaties geanalyseerd en verbeterd. Ik blijf dat doen. En ik ga me tegelijkertijd meer richten op het voorkomen van die problemen. Een onberispelijk datamodel en state-of-the-art set-based queries zijn nodig om een goed presterend en schaalbaar systeem te creëren. Ontwikkel je een applicatie met een SQL Server datalaag? Dan kan ik je helpen bij het opzetten van zo'n systeem. Word niet één van die toekomstige klanten met een grote en kunstig geschreven applicatie... op een onvolmaakt datamodel... gebruik makend van de verkeerde querytechnieken. Doe het nu, wanneer het nog uitsluitend voordelen heeft.

Ik deel graag mijn kennis. Neem eens een kijkje in de aanbevelingen voor SQL Server ontwikkeling. Ik ben benieuwd hoeveel van die regels je op dit moment overtreedt. Als je hulp en advies zoekt bij het toepassen van deze principes, neem dan contact met mij op. Ik doe alleen korte opdrachten. Ik werk met je samen, zet je op de goede weg, adviseer, deel genereus mijn kennis en vertrek weer. En ik blijf beschikbaar voor meer snelle vragen of korte opdrachten. Zowel voor advies als voor probleemoplossing.

januari 2021; de nieuwsbrief verschijnt enkele keren per jaar; aanmelden / afmelden