Введення в filestream - програмні продукти

Для підтримки типу FileStream потрібно на рівні бази завести відповідну файл-групу. Як flename для цієї групи виступає локальна папка в файлової системі. Ми не можемо взяти файл за довільним шляху, підсунути його SQL Serverу і сказати: дивись, це буде твоїм полем файлстрім в такий-то записи. Як ми побачимо далі, ми можемо лише скопіювати вміст цього файлу в полі, а зберігатися воно буде в тому файлі, який відведе йому SQL Server і назве відповідно зі своїми правилами.

Ось, що з'явилося після створення бази в директорії c: \ Temp:

Прописаний в filestreamовской групі filename є фолдер на локальному диску. Якщо запропонувати файлову кулі, який обматюкав:

create database TestFS1 on

primary (name = TestFS_data, filename = 'c: \ Temp \ TestFS_data.mdf'),

filegroup FG1 contains filestream

(Name = TestFS_media, filename = '\\ 192.168.0.1 \ c $ \ Temp \ TestFS_media')

log on (name = TestFS_log, filename = 'c: \ Temp \ TestFS_log.ldf')

Msg 5135, Level 16, State 2, Line 1

The path '\\ 192.168.0.1 \ c $ \ Temp \ TestFS_media' can not be used for FILESTREAM files. For information about supported paths, see SQL Server Books Online.

Msg 1802, Level 16, State 2, Line 1

CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

Зазначений шлях повинен існувати аж до n-1-го рівня, в нашому випадку - c: \ Temp. Фолдер TestFS_media існувати не повинен.

Можна створювати кілька файл-груп типу файлстрім:

проте в файлстрімовской файлгруппе може бути прописаний тільки один фолдер. Так робити не можна:

filegroup FG1 contains filestream

(Name = TestFS_media, filename = 'c: \ Temp \ TestFS_media'),

(Name = aaa, filename = 'c: \ aaa')

Тобто автоматично розганяти файлстрімовскіе файли по різних папках не вийде.

Після створення бази з файлстрімовской файл-групою можна створювати таблиці з файлстрімовскімі полями. В операторі CREATE TABLE поле типу filestream - це звичайний блоб (varbinary (max)) з атрибутом filestream.

При наявності в таблиці поля filestream обов'язковим також є наявність поля uniqueidentifier. Воно може бути без дефолтного значення, але три атрибути: unique, rowguidcol, not null є для нього обов'язковими. Хоча uniqueidentifier на те і uniqueidentifier, щоб бути unique, ця умова потрібно, щоб, наприклад, в новий запис не потрапило значення з попередньої. Крім того, оптимізатор набагато радісніше себе почуває, коли бачить явний unique. Атрибут rowguidcol дозволяє звертатися до поля не по імені, а як $ rowguid: напр. select $ rowguid from Media. Зрозуміло, що таке поле повинно бути одне на таблицю. Яку принципову важливість привносить цей атрибут, я, чесно кажучи, сказати не беруся. Просто бувають ситуації, які його потребують, і тому й бути. Раніше до них ставилася merge-реплікація, зараз ось додався файлстрім.

Наявність primary key не є обов'язковим. В даному випадку ми могли б обійтися без поля id. Я його ввів тут заради зручності, тому що в прикладі писати where id = <целое> простіше, ніж запам'ятовувати Гуїдо.

Апостеріорі дізнатися, чи має поле атрибут filestream, можна так:

select * from sys.columns where object_id = object_id ( 'Media', 'table') and system_type_id = type_id ( 'varbinary') and max_length = -1 and is_filestream = 1

За створенні таблиці в C: \ Temp \ TestFS_media (параметр filename групи filestream при створенні бази) з'явилася директорія на ім'я деякого Гуїдо, відповідна таблиці, в ній - ще одна теж з ім'ям якогось Гуїдо, соответствуюших полю filestream в цій таблиці (їх може бути кілька по числу таких полів).

Давайте тепер додавати в неї записи:

Після вставки в листової директорії з'явилося три файли з іменами Гуїдо, що відповідають трьом вставленим записів. Під NULLовое значення файл не заводиться, в БЛОБ має бути щось непорожнє. Порожній рядок - це вже непустоту.

Ось ми його підредагувати:

зберегли і подивилися, що вийшло:

Як приклад того, як це все знаходиться під контролем SQL Server, подивимося, як файлстріми бекапіть разом з базою. робимо

Потім Дропана базу, при цьому фолдер TestFS_media зникає з c: \ Temp разом з усіма своїми файлами, в яких зберігалося вміст поле файлстрім від різних записів таблиці Media. Ресторан базу:

Тут WITH MOVE - стандартна опція, в якій при відновленні вказується, що логічні імена файлів тепер будуть відповідати іншим фізичним шляхах. Ми говоримо, що c: \ Temp \ TestFS_media переїжджає в с: \ aaa. При цьому на диску з: автоматично створюється фолдер aaa, куди розгорнулася файлстрімовская файлгруппа. Так само, як і при створенні бази, весь вказується шлях повинен існувати від кореня диска до рівня n-1, тобто якби ми сказали with move 'TestFS_media' to 'c: \ aaa \ bbb ", не прокатали б.

Як і HierarchyID, про який я неабияк просторікував в попередніх постах, і геопросторові типи, просторікування на тему яких ще попереду, тип filestream підтримується в безкоштовному SQL Server, який SQL Express. Більш того, обмеження на розмір бази для SQL Express не поширюються на ті дані, що лежать в файлстрімовскіх БЛОБ.