FILESTREAM / FILETABLE Aclaraciones para la implementación

Recientemente nuestro equipo estaba buscando en FILESTREAM para expandir las capacidades de nuestra aplicación patentada. El objective principal de esta aplicación es administrar los diversos files PDF, imágenes y documentos en todas las piezas que fabricamos. Nuestra aplicación ASP utiliza algunas herramientas de terceros para permitir la visualización de estos files. Actualmente tenemos 980 GB de datos en el Fileserver. Tenemos alnetworkingedor de 200 GB de datos binarys en SQL Server que nos gustaría extraer, ya que no está funcionando bien, por lo tanto, FILESTREAM parece ser un buen compromiso para los dos principales problemas de almacenamiento / acceso a los datos.

Algunas cosas no son exactamente claras para nosotros:

  1. FILESTREAM puede o no puede almacenar sus datos en una unidad que no está conectada localmente. Ya tenemos un server de files con un RAID 10 (unidades de 1.5TB). Este server almacena todos los documentos en este momento, ¿tendríamos que mover estas unidades al server SQL para FILESTREAM? Eso sería un problema difícil de solucionar ya que el server también se está duplicando como server de aplicaciones (dos máquinas virtuales en un server físico).

  2. FILETABLE almacena los metadatos comunes sobre los files, pero ¿dónde está almacenada la parte de text completo para permitir la búsqueda de files como doc / docx? ¿Esto está separado? ¿Puede agregar criterios libremente a esto para search? Si es así, cualquier enlace para aclarar sería apreciado.

  3. ¿Se puede hacer reference a FILETABLE en otra tabla con una key externa?

Gracias de antemano

EDITAR: para aquellos que tienen estas preguntas, este video web cubrió todo y más en términos de la explicación de la extensión de files de 2008 a 2012 y las advertencias a tener en count (lo repito seriamente si pudiera): http://channel9.msdn.com/Events / TechDays / Techdays-2012-the-Netherlands / 2270

En conclusión, no utilizaremos FILESTREAM, ya que sería una forma de gran aumento para acomodarse a la inversión.

EDICION 2:

Actualización al n. ° 1: después de evaluar cuidadosamente FileTable, además de FILESTREAM, obtuvimos una combinación ganadora. Tuvimos que mover los files al nuevo server (no fue doloroso ya que estaban en la misma máquina virtual). Honestamente, tomó más time escribir una herramienta de extracción para volcar los datos binarys dentro de SQL al sistema de files.

Actualización al n. ° 2: esto fue separado, pero nuevamente Bob tuvo un seminario web excelente que explica esto: http://channel9.msdn.com/Events/TechEd/Europe/2012/DBI411

Actualización al n. ° 3: al usar la inheritance TFT, reciclamos la tabla de Docs que teníamos (less los enormes blobs binarys) que requería muy pocos cambios en nuestras aplicaciones henetworkingadas. Este fue un gran resultado para el equipo desarrollador.

La location en la que se almacenan los files para FileTables debe ser local o, al less, debe aparecer en SQL Server como local para que un controller san inteligente pueda engañarlo. Como las cosas de FileTables están basadas en FILESTREAM, imagino que las limitaciones son las mismas.

La búsqueda de tablas de files se realiza a través de la function de contenido que está documentada en MSDN, el criterio de búsqueda utiliza la misma syntax que FULLTEXT en la búsqueda de AFAIK.

Para todos los fines y propósitos, FileTable es una tabla típica, por lo que se puede unir, search o lo que sea. Lo único es que debe usar algunas funciones del server sql para cambiar las guías de FILESTREAM a algo más útil, como una ruta de file.