A schema defines a datastructure. IIRC each schema generates a table in the WinFS store where the data will be stored in. If you're going to create a Contact and store it, all info like Forename, Name, etc. will be stored in that table. Future Longhorn
applications are supposed make use of such schemas to store data in WinFS. Every piece of information will land inside the WinFS store, except for data that goes into fields with a specific datatype called varbinary(max).
The Contact schema for instance has no fields of that type, thus it will reside completely in the store. I don't have the structure of the Image schema at hand, so let's create our own (simpler) one. Assuming we've an Image type that has fields for Author,
Date, Location, etc. that are all varchar(256), all the data filled into these fields will reside in WinFS. But an image also contains compressed image data. You'd need a field called e.g. ImageData that will host the compressed data. Now you have either the
choice of using the image datatype (handles binary data, it's not tailored to images), which will cause the image data to be stored in WinFS as BLOB, or the varbinary(max) datatype which will act similar to the image datatype, but cause the data to be stored
in a filestream on the disk. Both cases would work fine. However if you were to consider performance issues, the possibility of the image data to be changing a lot and/or the need of random I/O, you'd need to make use of filestreams instead of BLOBs. Latter
ones don't offer any real flexibility.
In short, it means, that data will only be slapped onto the NTFS part if fields in a schema make explicit use of filestreams. So, it's not JUST a metadata store.
There's naturally also a simple File type in WinFS, whose purpose is to manage files inside WinFS which the file promoter couldn't recognize (JPEGs or MP3s are standard formats, but what if you copy some file with obscure format into WinFS? Thus you need an
One thing for sure is that, at least in development mode, maintenance is much easier with files in the file system space than raw disk partitions. I can easily shutdown the server copy the files to a new place, restart the server, attach those new files
as a different database in like 2 minutes.
Good point, though these types of scenarios aren't likely on multi-gigabyte databases