> -storing files into databases, including some metadata > (the easy part)
I would see the mapping from relational model to filesystem: relation (table) = filesystem (defines a set of files that share the same set of attributes). tuple (row) = file that has the content value and attribute values attribute = one of the attributes has to be decided as content and the rest of the attributes are file attributes. Problems: You have to store the decision of which attribute is to be the content attribute in vfs. Messy. It will get lost if it is not in the database. Someone might want to see one database as one filesystem. Then files in that same filesystem would have completely different attributes and content stored in different attribute too. All tables should not contain any duplicates and have key attribute that would uniquely identify the tuple (row, file). Unfortunately sql (and current databases) don't enforce this. If you want to see one database as one filesystem then the path would be schema/tableName/uniqueId If one table is one filesystem then the path would be only uniqueId. I can see the benefit of this project in the possibility of adding attributes freely to filesystem. But it is going to me a bit "messy" because of the heterogenous nature of database products, sql dialects, and jdbc driver implementations. Also relational model is stronger than simple hierarchical filesystem model so that needs to be kept in mind. - rami --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
