Недавно наша команда изучала FILESTREAM, чтобы расширить возможности нашего собственного приложения. Основной целью этого приложения является управление различными PDFS, изображениями и документами для всех деталей, которые мы производим. Наше приложение ASP использует несколько сторонних инструментов для просмотра этих файлов. В настоящее время у нас есть 980 ГБ данных на файловом сервере. У нас есть около 200 ГБ двоичных данных в SQL Server, которые мы хотели бы извлечь, поскольку они неэффективны, поэтому FILESTREAM, похоже, является хорошим компромиссом для двух основных проблем хранения / доступа к данным.

Несколько вещей нам не совсем понятны:

FILESTREAM Can or Cannot store its data on a drive that is not locally attached. We already have a File Server with a RAID 10 (1.5TB drives). This server stores all of the documents right now, would we have to move these drives to the SQL Server for FILESTREAM? That would be a tough bullet to bite since the server also is doubling as the Application Server (Two VMs on one physical server).

FILETABLE stores the common metadata about the files but where is the Full Text part of it stored to allow searching of files like doc/docx? Is this separate? Are you able to freely add criteria to this to search by? If so any links to clarify would be appreciated.

Can FILETABLE be referenced in another table with a foreign key?

заранее спасибо

РЕДАКТИРОВАТЬ: Для тех, у кого есть эти вопросы, это веб-видео охватывало все и многое другое с точки зрения объяснения потока файлов с 2008 по 2012 год и рассуждений о них (я бы серьезно повторил его, если бы мог)http://channel9.msdn.com/Events/TechDays/Techdays-2012-the-Netherlands/2270

В заключение мы не будем использовать FILESTREAM, так как это будет огромным подъёмом для инвестиций.

РЕДАКТИРОВАТЬ 2:

Обновление до # 1 - После тщательной оценки FileTable в дополнение к FILESTREAM мы получили выигрышную комбинацию. Нам действительно пришлось перенести файлы на новый сервер (это не было болезненно, поскольку они находились на одной и той же виртуальной машине). Честно говоря, потребовалось больше времени, чтобы написать инструмент извлечения для передачи двоичных данных в SQL в файловую систему.

Обновление до # 2 - это было отдельно, но снова у Боба был отличный вебинар, объясняющий это:http://channel9.msdn.com/Events/TechEd/Europe/2012/DBI411

Обновление до №3. Используя TFT-наследование, мы переработали имеющуюся у нас таблицу документов (за исключением огромных двоичных двоичных объектов), что потребовало очень небольших изменений в наших старых приложениях. Это был огромный результат для команды разработчиков.