Aki még emlékszik rá, valamikor 2004 táján volt egy olyan ötlet, hogy az NTFS valamiféle adatbázis irányba megy el, így a Vista mögött WinFS néven lesz valami hibrid tároló. Még demóztam is annak idején, de aztán nem lett belőle semmi.
Most, 2012-ben az FileTable SQL Server újdonságot látva WinFS feelingem támadt. Lássuk, mi ez?

Nagy fájlok és a relációs adatok együttes tárolása gyakran visszatérő feladat. Pl. egy website fényképeket publikál, amelyekhez le kell tárolni a fényképeket mint nagytömegű bináris adatot, és hozzá tucatnyi metaadatot a kép méretéről, készítőjéről, stb. A metaadatok könnyen letárolhatók relációs sémában, de a fájl adatok mindig is problémát jelentettek, mivel a relációs adatbáziskezelők nem nagyméretű adatok tárolására tervezettek, hanem sok kicsire.
Az SQL Server 2008-ban bevezetett FILESTREAM attribútum segítségével már tudtunk nagytömegű adatokat hatékonyan tárolni, amely látszólag adatbázisban tárolja az adatokat, valójában fájlrendszerben, a tranzakcionális épség megtartása mellett. Az így tárolt adatokat el lehet érni SQL SELECT paranccsal is, mintha relációs adat lenne, de tranzakcionális fájl apin keresztül is, amely hatékonyabb elérést biztosít. Utóbbi viszont csak tranzakció megnyitása után engedélyezte a kipublikált fájl megosztás elérését, így azt azt az arre fel nem készített alkalmazások közvetlenül nem tudták elérni fájl apival (CreateFile függvény, .NET FileStream osztály, stb.).
Az SQL Server 2012-ben bevezetett FileTable a FILESTREAM funkciót fejleszti tovább. Belül FILESTREAM alapon látszólag táblában, valójában fájlokban tárolja az adatokat, kívülről viszont teljesen úgy lehet elérni őket, mintha egy fájlmegosztás fájljait és könyvtárait látnánk. A FileTable adatok eléréséhez nem kell (de lehet) tranzakciót nyitni, így közönséges módon, mintha tényleg fájlokat látnánk elérhetőek az adatok.
Közelebbről, a FileTable valamely sora egy fájlt vagy egy könyvtárat képes tárolni. Az adatok a fájlrendszerhez hasonlóan hierarchikusan vannak elrendezve. Belül contraintekkel és triggerekkel biztosítják, hogy az igazi fájlrendszerhez hasonlóan működjön. 10 fájl attribútumot is tárolnak (hidden, readonly, stb.). Tartalmaz egy fájl típust azonosító oszlopot is, hogy a FullText kereső tudja, milyen tartalom van benne (rtf, doc, stb.)
SQL szemszögből az adatok elérhetők SQL parancsokkal is, és a backup/restore is kezeli, azaz teljesen integráns része lett az SQL Servernek, míg kívülről teljesen az az élményünk, hogy fájlrendszert látunk.
Nézzünk egy egyszerű példát FileTable létrehozására:

alter database AdventureWorks2012
ADD FILEGROUP FsGroup CONTAINS FILESTREAM;

alter database AdventureWorks2012
ADD FILE (NAME = Fs, FILENAME = 'c:\data\filestream1')
TO FILEGROUP FsGroup;

ALTER DATABASE AdventureWorks2012
SET FILESTREAM (NON_TRANSACTED_ACCESS = FULL, DIRECTORY_NAME = N'gyoker');

CREATE TABLE FtStore AS FileTable
WITH (FileTable_Directory = 'Ft',
	FileTable_Collate_Filename = Latin1_General_100_CI_AS);

Intézőben közönséges megosztásként látszik a FileTable, létrehozhatunk benne könyvtárakat és fájlokat:

Így érhető el a FileTable SQL oldalról:

SELECT * FROM [AdventureWorks2012].[dbo].[FtStore];

Az eredményhalmaz ketté van vágva a könnyebb olvashatóság kedvéért:

A FILESTREAM vagy FileTable adatokat igazán hatékonyan a megosztáson keresztül, fájlkezelő műveletekkel lehet jól kiaknázni, mivel ilyenkor az adatok nem kerülnek be a Buffer Cache-be, így nem tolják ki onnan a már cache-elt kisebb relációs adatokat.

Egyetlen fura pont van csak az egészben, hogy notepadban nem lehet megnyitni és elmenteni a FileTableben tárolt szövegeket, mert a notepad Memory Mapped File apival nyitja meg a szöveget, amit nem támogat a FileTable redirectora… Csak sima CreateFile api vagy .NET-ből a FileStream az, amivel meg lehet nyitni a benne levő dolgokat. A WordPad például nem trükközik, nem használ Memory Mapped File-t.

Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.