chefren wrote: > > On 1/9/07 1:22 PM, Richard P. Welty wrote: > > .. > > > yes, it seems to me that the author of this proposal doesn't really > > understand the huge gap between a conventional file system and > > a full up RDBMS. > > I do. > You don't. How do you handle physical defects in the storage media? How do you store the RDMS inside the RDMS? How do you bring up the RDMS from a cold start on the bare hardware? How do you determine which attributes exist and how big each is? Once that is done, how do you add attributes or change their sizes?
> > > let file systems be good file systems, and let the RDBMS or OO DBMS > > be a good DBMS. > > Then explain to me what a good file system is! I can lose a sector without losing the entire disk. If the filesystem is damaged I can recover information from it. Not only that, but I can actually use a disk that is not 100% in a production environment. (Disks have effectively been that way for a long time) > > > Filesystems need versioning and replication =build in=, you cannot > backup a 750G harddisk now and then, these days everything is "on > line" and you need continous copies on multiple locations. How do you "version" the boot sector? > > Restoring a 750GB disk (who has tapedrives to store 750G?) costs about > a minute a GB, clueless path. With or without error recovery? > > > And a filesystem with true versioning and replication is as close to a > database as you can get. What is this "true versioning"? How does it differ from whatever whoever happens to call "versioning"? What is the granularity that distinguishes one version from the next? Why? Depending, with cheaply available current technology, one year can be far too fast. You move stuff from place to place. An eyedropper can be far too big. An 85-ton truck can be far too small. One microsecond can be far too long. > > So lets do that right. > > FFS is OK for now but not for the future. > > +++chefren
