Re: 'Theoretical' DB OS

From: <christianlott1_at_yahoo.com>
Date: 24 Mar 2007 15:02:09 -0700
Message-ID: <1174773729.282910.71590_at_b75g2000hsg.googlegroups.com>


If the file system is attribute based it can either emulate a DOS file type through a relation or declare it as an attribute domain.

I'm looking at computers as a whole and not necessarily just the PC. The only thing in common seems to be the track/sector layout of disks. This can be seen as theoretically important.

If all the files are attributes, there is only one file type except the boot file.

Does each attribute file need a key? I've read that at least one dbms stores a 'superkey' for each attribute.

If I'm not mistaken that would allow me to create a relation where each superkey would match and be stored with each attribute. The superkey would need to be a globally unique number given by the operating system. I'm not sure yet if I could derive this superkey from track/sector information.

The only way that would work is if no true deletion was allowed.

Maybe at some point after creating a fixed database scheme, when it goes into production you don't want to allow for true deletion from the disk where the attribute or relation would be marked as 'deleted' and all views would normally mask this out as deleted or archived.

Maybe a combination of time stamp and user id and increment would work well. Obviously I'm trying to save space per attribute file. And this superkey would be fixed width or delimited?

So you see, I am having some problems thinking about this.

Christian Received on Sat Mar 24 2007 - 23:02:09 CET

Original text of this message