blowdart wrote:
You're assuming that the data is actually stored in a database. I don't
believe that's the case, the database is there to make relationships
and object schemas for the underlying files. You're not going to see
the contents of c:\windows inside a database, but what you would see is
your Outlook contacts in there, shared between applications.
I'm waiting for the documentation download to be available
I should save a copy of the following reply, because someone has to keep reposting it:
WinFS is a database with O/R framework tacked on top of it. And some
more glue code. All data that isn't a varbinary(max) field in the
schema will be stored in the database. The varbinary(max) fields
however will spawn a file in some hidden location, allowing random IO
on the data, something which is problematic in a database, unless it
has been geared towards (SQL Server is not).
The all too overused contact data sample shows what I mean. Nowhere it
needs a varbinary(max) field, because it won't store any type of
unstructured data that needs random IO, thus it can reside completely
inside the database. An email schema however will likely store the
email fields and the message body inside the database, but also relate
to attachment items, which will put the data they contain onto the NTFS
part.
Whether the data gets into the database or not (a part of it always
will), depends on how a developer writes their item schemas and what he
decides is unstructured or not.
There's a special built-in file schema, which emulates old files. That
schema allows you to copy files "into" the WinFS database. That means,
all information like filename, filedates and such are stored in the
database, an additional field will reference the hidden data file
(which resides in x:\System Volume Information\someguids\etc). These
files can be accessed as usual, but via UNC paths, at least as of 4074
(this might have changed). These paths looked like
\\localmachine\defaultstore\somefolder\filename.ext
There are also things called file promoters, that intervene when
copying files into WinFS, and turns them in specialized schemas, that
are very likely derived from the file schema to allow legacy
applications accessing it. Those derived schemas allow the file
promoters to extract relevant metadata and put them into the new
fields. The file promoters also react when the affected items are
changed.
That's all, I hope.
--edit: What might be a problem however is how data will be spread
across multiple WinFS enabled partitions. Especially because saving
things will probably go through a fancy ambiguous dialog. I've asked
the WinFS guys about it last year, and they meant they're actively
looking into that one. But I've yet to know how this will play out.
--edit2: And oh, only data you want in there will go in there. Program
files and everything will still go onto NTFS. Unless they're merging
NTFS and SQL Server for real. Theoretically, to do so, it would just
need a bitmap that differs which page is used for filedata and which
for the database. Until there, not really a problem. However the
bootloader will be one, because it would need to be able to parse the
data tables and relations to figure out where things are.
Channel 10: Black Friday Deals on Windows 7 Machines
ASP.NET: Presenting in Europe Next Week
WindowsClient: You know your post rate has gone down...
Silverlight: Geek Profiles – Scott Guthrie
