Afgelopen week las ik iets over tabel fragmentatie. Hier had ik eigenlijk nog nooit van gehoord. Wel van bestandsfragmentatie en dergelijke, maar nog nooit dat tabellen ook gefragmenteerd kunnen raken.
Op zich wel logisch natuurlijk als er veel in wordt gewijzigd.
Belangrijke punten waaraan je tabel fragmentatie aan kunt herkennen zijn:

• Langzame performance
• Veel disk activiteit
• Weinig gebruik van caching

Fragmentatie treedt op wanneer er data wordt gewijzigd met INSERT, UPDATE en DELETE statements.
Deze queries kunnen ervoor zorgen dat er ‘gaten’ in de pages van SQL ontstaan. Met de query DBCC SHOWCONTIG` kun je controleren hoeveel fragmentatie in de tabellen van je database is.

Zelf was ik geschokt toen ik de resultaten zag. Er was nu al redelijk wat fragmentatie ontstaan in de tabellen van dit weblog. Dit is dan wel in de ontwikkel omgeving, maar toch.
Om de fragmentatie te reduceren kan er gebruik worden gemaakt van twee populaire queries, namelijk DBCC INDEXDEFRAG en DBCC DBREINDEX.
Deze twee statements kunnen in een Maintenance Plan worden opgenomen die bijvoorbeeld iedere week of maand (afhankelijk van het gebruik van de database) kan worden uitgevoerd. Zodoende blijven de indexen up-to-date en zal de fragmentatie minimaal blijven. Belangrijk om te weten is dat het DBCC SHOWCONTIG-statement in SQL Server 2005 is vervangen door sys.dm_db_index_physical_stats

Een van de dingen die ik vandaag moest maken in MS-SQL was een Split-functie. Eerst was ik van plan deze in C# te maken en dan via een dll in SQL Server 2005 te laden. Dit heeft echter als nadeel dat je weer code binaries in SQL gaat gebruiken en dit lastig kan blijken om bij klanten door te voeren. Uiteraard is het wel vette functionalteit, maar als het niet hoeft, doe ik het liever niet.

Gelukkig hebben meer mensen het probleem ondervonden dat er geen Split-functie zit in T-SQL, dus hadden andere mensen deze al gemaakt.
Aangezien ik niet werkzaam ben bij Wieluitvinders B.V. heb ik maar besloten andermans code hiervoor te gebruiken. Vadivel M had al een mooi voorbeeld op z’n weblog staan, wat hier is te vinden: https://vadivel.blogspot.com/2006/05/split-function-in-sql-server-method-1.html
Deze heb ik dus ordinair gekopieerd. Even later zag ik dat hij dit ook heeft gedaan, omdat nagenoeg dezelfde code op nog tig andere pagina’s was te vinden. Bij deze deel ik dus hier ook nogmaals de Split-functie.

Create function Split (@String nvarchar(4000), @Delimiter char(1)) 
    Returns @Results Table (Items nvarchar(4000)) 
    As Begin Declare @Index int Declare @Slice nvarchar(4000) 
        Select @Index = 1 
        If @String Is NULL Return 
        While @Index != 0 
        Begin Select @Index = CharIndex(@Delimiter, @String) 
            If Index != 0 
                Select @Slice = left(@String, @Index - 1) 
            else 
                Select @Slice = @String 
                Insert into @Results(Items) Values (@Slice) 
                Select @String = right(@String, Len(@String) - @Index) 
                If Len(@String) = 0 break 
        End 
Return 
End

Het voorbeeld dat hij gebruikt

Vandaag moest ik in SQL 2005 een functie maken met wat functionaliteit. Uiteindelijk had ik maar bedacht dat er gebruik gemaakt moest worden van een tijdelijke tabel waar m’n tijdelijke informatie in werd geplaatst. Vanuit die tijdelijke tabel kon ik dan weer extra mutaties en selecties doen om zo tot het uiteindelijke resutlaat te komen.

Nu ben ik niet enorm slecht in SQL en dacht ook mooi op weg te zijn. Alle functie functionaliteit had ik eerst in een query geschreven, zodat er eenvoudig getest kon worden of alles werkte. In m’n query kreeg ik nu het gewenste resultaat. De exacte code had ik gekopieerd naar een lege functie wilde ik de functie aanmaken. Kreeg ik ineens een fout dat er onjuiste tekens in m’n functie stond. Kan gebeuren natuurlijk. Een verkeerde komma of letter maakt zelfs van Jezus een ketter. De hele functie nogmaals nalopen, maar ik kon niet echt een fout vinden. Na wat proberen en debuggen kreeg ik wel een foutmelding dat je geen tabel mocht aanmaken in een functie. Dat vond ik persoonlijk toch wel de meest debiele fout die ik kon bedenken en kon het ook niet geloven. SQL draait om tabellen en dan kun je niet eens een tijdelijke aanmaken in een functie. Daar moet dan weer een Stored Procedure voor worden aangemaakt.

Vandaag kwam ik een interessante post tegen op een ander weblog, namelijk dat je in SQL Server 2008 gebruik kunt maken van een zogenaamde Filtered index. Dit houdt in dat je een index kan aanmaken op een stukje van de tabel. Nu lukt het mij zelf niet om direct een groot voordeel van een filtered index te bedenken, maar ze zullen er waarschijnlijk wel zijn.

Andrew Fryer heeft wel een probleem situatie van ‘vroeger’ kunnen oplossen met behulp van een filtered index. Hij beschrijft namelijk de situatie dat een kolom in je tabel altijd unieke waarden moet hebben, maar ook NULL als waarde mag bevatten (dus leeg is). Op z’n eigen weblog beschrijft hij z’n werkwijze (https://blogs.technet.com/andrew/archive/2008/02/21/sql-server-2008-filtered-indexes.aspx).

Wat hij doet is de volgende code gebruiken in SQL Server 2008.

create unique index production.nullidx on production.product(code) where production.product(code) is not null

Wat ik hier van op maak is dat er een unieke constraint op de kolom production.nullids komt te staan ALS het veld is ingevuld. Ik twijfel er niet aan dat dit handig kan zijn in enkele situaties.
Ook denk ik dat dit soort indices ook in m’n eigen applicatie(s) wel kunnen worden toegevoegd, echter heb ik deze nieuwe feature nog niet gemist in m’n huidige brouwsels.

Vandaag was ik bezig met het maken van m’n basis weblog functies.

Nu was ik belandt bij het aanmaken van posts, toch wel een essentieel onderdeel. Als identifier maak ik gebruik GUID’s en in SQL heb ik dan de newsequentialid() gebruikt.
Uiteraard is dit enorm handig, maar niet direct in combinatie met L2SQL.

Wanneer je zelf geen actie onderneemt dan wordt er gewoon een lege guid toegevoegd.
Gelukkig vond ik al redelijk snel een oplossing hiervoor op Nick Kusters z’n weblog (https://www.nickkusters.com/ViewArticle.aspx?ArticleID=29)
Je moet dus zelf in de designer aangeven dat de waarde in de database wordt berekend.

Dit kun je zelf ook aangeven in je mapping.xml, maar dan zou je dit iedere keer moeten doen wanneer je deze update.

Aangezien ik daar niet zoveel zin in heb, moest ik maar weer eens testen of een dbml-bestand toch geen optie is.

Gezien m’n vorige post hier, is dat dus ook weer gelukt. Zo zie je maar weer dat je toch een beetje vertrouwen moet hebben in Microsoft development en niet eigenwijs bezig gaan.

Vorige week had ik het er over dat de standaard dbml-bestanden die je kunt maken in Visual Studio 2008 niet goed genoeg zijn, aangezien je die lastig in een n-tier situatie kunt gebruiken.

Hier moet ik weer op terug komen.

Ik ben nu iets meer ervaren in het hele L2SQL gebeuren en zie nu dat ik niet gelijk had. Je kunt een dbml-bestand prima gebruiken in een n-tier situatie.

Je kunt dus gewoon via de user-interface je spullen blijven bewerken, zonder gebruik te maken van SQLMetal.

Dit is uiteraard goed nieuws, afgezien van het feit dat ik nu al een week zit te prutsen met SQLMetal.

Ok, hierdoor heb ik wel wat ervaring opgedaan hoe L2SQL werkt en dergelijke.

Het is dus niet volledig verloren tijd en ik ben blij dat ik er nu met m’n thuis-project achter kom in plaats van op het werk.

Nou ja, nu ga ik dan maar weer m’n dbml-bestand aanmaken en de rest weggooien.

Eigenlijk kan alles gelijk blijven aan wat ik nu heb. Waarschijnlijk moet er her en der wat aan worden gepast, maar dat zal niet enorm erg zijn.

Dus wanneer je gebruik gaat maken van L2SQL, maak dan gewoon een dbml-bestand aan en ga niet eigenwijs je eigen spullen aanmaken.

Zo, ik heb het voor elkaar.

Met de methode hoe ik nu LINQ to SQL heb toegepast in m’n solution kan ik toch de aloude n-tier architectuur blijven behouden.

Om dit te bewerkstelligen moet je jammergenoeg wel afstappen van de eenvoudige grafische user interface die Visual Studio 2008 aanbied. Je moet nu namelijk van de console applicatie SQLMetal.exe gebruik maken.

Ook wel te doen natuurlijk, maar het is een beetje jammer dat dit niet standaard in VS.Net 2008 kan.

Eerst heb ik vandaag enkele posts van Scott Guthrie doorgelezen.

De belangrijksten waren deze wel.

Using LINQ to SQL (Part 1)
https://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx

LINQ to SQL (Part 2 - Defining our Data Model Classes)
https://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx

LINQ to SQL (Part 3 - Querying our Database)
https://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx

LINQ to SQL (Part 4 - Updating our Database)
https://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx

In een van deze posts stond een linkje naar een video post van Mike Taulty. Op zijn weblog heb ik het volgende filmpje bekeken:

https://mtaulty.com/videos/nuggets/l2s/04_mt_l2s_codegentools.wmv

Dit is een enorm informatief stukje over LINQ to SQL.
Wanneer je dit filmpje hebt gezien kun je met een beetje fantasie wel begrijpen hoe je nu een n-tier architectuur kunt toepassen.

Ten eerste maak je de mapping XML en mapping CS bestanden aan.
Zelf heb ik dit gedaan door de volgende command-line te gebruiken in de Visual Studio 2008 Command Prompt in te tikken:

Hoewel LINQ to SQL me gisteren wel het ei van Columbus leek ben ik daar vandaag niet meer zo zeker van.

Vanavond heb ik een beetje gezocht hoe je LINQ to SQL in een n-tier architectuur kunt gebruiken. Wanneer je dit in Google opzoekt zie je veel probleem verhalen en weinig successen.
Op de MSDN-site staat wel globaal beschreven hoe je het zou kunnen paar een echt real-life voorbeeld is niet echt aanwezig. Tenminste niet zoals ik het graag wil zien.

Via deze link https://msdn2.microsoft.com/en-us/library/bb882661.aspx krijg je wel weer genoeg leesvoer.

Vooral de hoofdstukken Implementing Business Logic (LINQ to SQL) ( https://msdn2.microsoft.com/en-us/library/bb882671.aspx ) en Data Retrieval and CUD Operations in N-Tier Applications (LINQ to SQL) ( https://msdn2.microsoft.com/en-us/library/bb546187.aspx ) vond ik enigzins interessant.

Het lijkt alsof je de objecten die je vanuit je dbml bestand (LINQ) krijgt worden ge-detached wanneer je ze in een andere laag gebruikt. Zodra je de wijzigingen wilt opslaan moet het gehele originele object weer terug worden gekoppeld, samen met een kopie van het originele object met daarin de wijzigingen. Of je maakt de wijzigingen in de LINQ-laag, maar dan kan het zijn dat je zo’n 40 parameters aan een functie moet toevoegen. Dat is natuurlijk ook niet echt overzichtelijk.

Vandaag voor het eerst een zogenaamde Distributed query in SQL gemaakt.
Simpelgezegd houdt dit in dat je een query doet op een andere database en de data daaruit gebruikt in je eigen database.

Hier kun je het woord database op meerdere manieren interpreteren. Volgens mij kun je ook wel een Distributed Query doen op een XML-bestand, wat dus niet een echte database is.

Ik heb vandaag dus data uit een tabel van een Access database via een insert-statement in SQL geimporteerd. Normaliter zou ik zoiets wel doen met [Ctrl]+[C] en [Ctrl]+[V], maar het betrof hier ongeveer 650.000 records (een postcode tabel). Aangezien het kladblok maar 65.000 records in het geheugen kan laten staan zou ik deze actie minstens 10x moeten doen. Daar houdt ik niet echt van.

Dus op zoek naar een alternatief, dat ik vond in dit type query.

Ten eerste moet je dit activeren in MS SQL Server 2005. Standaard staat dit om beveiligingsredenen uit. Door middel van de volgende query uit te voeren kun je de functionaliteit activeren:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

sp_configure 'Ad Hoc Distributed Queries', 1;
GO
RECONFIGURE;
GO

Ik denk zelfs dat alleen het onderste gedeelte (de laatste 4 regels) ook wel goed genoeg zijn, maar dat heb ik niet getest.

Gisteravond ben ik begonnen met het maken van de database voor m’n nieuwe prive project.

In m’n ontwerp maak ik gebruik van GUID’s in plaats van de reguliere ‘oplopende unieke teller’ welke vaak als primary key wordt gebruikt.

Het voordeel van een GUID, is dat deze altijd uniek is. Een systeem zal nooit dezelfde GUID maken.

Nadeel van een GUID is wel dat ze volgens mij meer bytes in beslag nemen als een integer. Nog een nadeel is dat ze voorheen met de functie newid() geen logica hadden. Het systeem maakte wel altijd een nieuwe GUID, maar er werd niet gegarandeerd dat deze op- of aflopend zou zijn.

Nu is er een nieuwe functie in SQL 2005 geintroduceerd, namelijk de newsequentialid(). Zoals de naam al doet vermoeden maakt deze een nieuwe GUID, en deze is altijd hoger als de vorige. Je hebt dus een oplopende primary key. Dat is handig met sorteren en voor de indexes, aangezien er dan sneller kan worden gezocht naar nieuwe records en dergelijke.

Probleem met de functie newsequentialid() is dat je deze niet kunt gebruiken met het designen van een tabel in Management Studio van SQL 2005. Je krijgt dan een validatie error bij het gebruik van deze functie.