Handleidingen, gebruiksaanwijzingen, technische fiches, beheersdocumenten, plannen, tekeningen en andere digitale documenten aanbieden via je e-business site biedt een grote toegevoegde waarde voor je klant. Deze documenten opslaan en beheren in de database van een e-business site is echter geen sinecure. Met als gevolg dat je zeer regelmatig langs sites surft waar de links voor pakweg handleidingen of andere documenten doodlopen. Het beheer van dergelijke ‘blob-data’ wordt echter sterk vereenvoudigd in de nieuwe SQL2012.
Blob-geschiedenisles
Destijds (SQL2008) was er steeds het terugkerende probleem betreffende het stockeren van blob-data. Met blobdata worden Word-documenten, pdf’s, jpg’s en dergelijke bedoeld: binaire data die behoorlijk groot in omvang kan worden.
De meest gehanteerde oplossing bestond erin om metadata en het path (de link) naar de blob in de sql-database te stockeren en de eigenlijke blob in het filesysteem. Steeds terugkerend probleem was echter het synchroon houden van de data tussen de twee verschillende systemen. Binnen de database waren er records aanwezig die naar bijvoorbeeld jpg’s verwezen terwijl de bijhorende files niet meer aanwezig waren of omgekeerd. Hiervoor werden wel programma’s ontwikkeld om een opkuis van niet meer gebruikte blob-data uit te voeren maar dit werd niet in een transactie uitgevoerd waardoor gelockte files toch weer bleven bestaan.
Daarnaast waren er ook heel vaak problemen wanneer een backup moest terug gezet worden (restore). Bij een database kan je een point-in-time restore uitvoeren, bij filesystem backups niet. Neem als voorbeeld dat om 14u een fout ontdekt werd waardoor de database diende gerestored te worden naar de toestand van 10u30. Voor de database kon dit, maar voor het het filesysteem kon enkel een restore gebeuren naar de toestand van bijboorbeeld 00:00 (de dagelijkse backup). Alle wijzigingen aan blob-data tussen 10u30 en 14u lopen dan uiteraard niet meer synchroon tussen database en filesysteem, opnieuw een probleem dat moeilijk op te lossen valt.
Het alternatief bestond erin om de blob-data toch in de database te stockeren en niet in het filesysteem. Dit had echter een zwakke performantie als nadeel want de blob-data diende immers eerst in memory binnen de Sql-server opgenomen te worden wat de werking van de database vertraagde.
SQL2008(R2) lost het probleem gedeeltelijk op
In Sql2008(R2) was er de nieuwe feature filestream die hiervoor een oplossing bood. Filestream laat toe om binnen de context van een sql-transactie blobdata te lezen en te schrijven. Het grootste voordeel van filestream is dat het je toelaat om blob’s in de database te stockeren zonder het grootste nadeel (performantie). Het laat immers toe om de binaire data zeer snel te lezen of schrijven via een win32 api, zodat deze niet eerst binnen sql-memory dient geladen te worden. Bijkomend voordeel van filestream is dat de blobdata gewoon binnen een sql backup/restore is opgenomen. En de backup en restore identiek is zoals bij een database waarin geen filestream gebruikt wordt. Filestream is bijvoorbeeld bruikbaar om pdf-documenten van pakweg 20 MB te stockeren en snel toegankelijk te maken via een website. Enige nadeel betreffende filestream was dat het niet eenvoudig was om op een correcte/snelle manier de data te bewaren en op te vragen.
De blob-toekomst ziet er rooskleurig uit!
Voor de binnenkort verwachte SQL Server 2012 werd er verder gewerkt op filestream, met als resultaat FileTable. Binnen een filetable kan je files en folders bewaren in de database. Deze files worden echter ook beschikbaar om te beheren en openen via een share in windows-applicaties. Bij de creatie van een filetable object geef je een bijhorende share-naam op waarin je allerlei blob-files en/of folders kan bewaren. De files die zich in deze share bevinden kan je met hun respectievelijke programma’s openen en editeren. Dit werkt dus net hetzlfde als gewone folders in Windows.
Binnen de sql-database kan je met het aangemaakte filetable-object alle properties van de in deze share bewaarde documenten opvragen. Als je in de share nieuwe files plaatst, dan verschijnen die ook in het filetable object in de SQL database. Ook in de andere richting werkt dit hetzelfde. Als je een record verwijdert binnen het filetable object dan wordt ook de file binnen de share verwijderd.
Het gebruik van het FileTable object binnen SQL is identiek aan andere tables met als enige verschil dat de structuur vast is. Het bevat onder andere creationtime, lastwritetime, lastaccesstime, IsHidden, … Dus alle soorten properties die je binnen het gewone filesysteem ook kan opvragen. Filetable behoudt dus alle voordelen van filestream, maar zorgt voor een veel eenvoudiger gebruik, beheer en toegang van de blob-data.
Daarbij komt nog dat je fulltext search kan gebruiken bovenop filetable, maar dat is voor een volgende blogpost!
