Darren New wrote:
> 
> You can. You're just storing the metadata in the file name. If you run 
> thru the full path, you can extract whatever metadata you need 
> temporarily. Using a file system as a database this way is a pretty 
> common technique. (There even used to be a pre-SQL database mechanism 
> called "heirarchical database" that worked just like that.)
> 

Well yes - not as easily and only up to some file system imposed limit.

Some scheme to store data within the file path/name is certainly 
possible (I use it all the time).  As the amount of metadata grows 
though it becomes cumbersome and moving to a proper database makes sense.

Such a scheme is not assisted by the OS or most tools and utilities. 
For example I could easily botch part of the path by swapping the 3rd 
and 7th elements.  Or format dates wrongly in the 4th element.  Nothing 
helps me to keep the scheme in place.

Actually I could store the content of a file in its filename (up to some 
limit) and then just make the file have the EOF character in it.  If it 
is a binary file then just ASCII encode it!  Extreme case.

Eg. C:\Shopping List\Groceries\20090524\Sunday\Tea, Biscuits (sweet), 4 
Oranges, Fresh Corn on the cob (or canned if none available) and so on 
until the OS won't let me continue.txt

Whereas if I put the metadata into database fields or file attributes 
then some validation is enforced by the field type.  There are well 
supported concepts like sorting and searching.

Since you bring up hierarchical databases, I note that the relational 
model has pretty much won that debate.  Sure there are still examples of 
H databases but I think you would agree that R is dominant today?  And 
for the same reasons that I advocated the approach to Tim.

Relational can't solve all problems but it is generally a closer 
representation of the data, easier to manipulate, less redundancy, 
better supported by tools ...

Post a reply to this message