Re: 'Theoretical' DB OS

christianlott1_at_yahoo.com wrote:

> 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.

You are using well-defined words, and I am absolutely convinced you haven't the foggiest what they mean. Deriving a number from the track/sector is ass backward. Received on Sun Mar 25 2007 - 00:17:43 CET