On Mon, Jan 08, 2007 at 10:14:12PM +0100, chefren wrote: > >Firstly, it eliminates the choice that we currently have: say mysql versus > >Oracle versus BerkeleyDB versus pgsql etc. > > And why do you forget the single OpenBSD choice named: FFS?
Well, it's not the only one, although probably the best supported read/write one: # mount mount mount_ext2fs mount_msdos mount_portal mount_xfs mount_ados mount_ffs mount_nfs mount_procfs mountd mount_cd9660 mount_mfs mount_ntfs mount_udf FFS implements standard Unix semantics and gives very good reliability for a wide variety of common purposes. If you want database semantics, you stick a database on top. This follows the Unix principle of dividing functionality into modules which are combined in useful ways, with the choice of substituting a more appropriate one for your needs. > > Each application currently can > >choose an appropriate database given constraints of DB size, speed, > >indexing > >algorithms, ease of administration etc. It sounds like you're proposing a > >"one size fits all" alternative. > > Yep, because you definitely want to be able to interchange data > between everything. You also want to exchange files between Linux and OpenBSD; this doesn't mean that both platforms *must* use the same filesystem natively. Why did Oracle buy Sleepycat, giving them both Oracle DB and Berkeley DB in their product portfolio? I'd say because these are tailored for two completely different areas (enterprise databases and embedded systems). OpenBSD is used in both these areas. > I want to eliminate the need for Oracle or whatever other databases... Then IMO you have impossible conflicting goals: - something which is small and fast (as it is to be an integral part of the O/S) - something which is huge and featureful (as it is going to supercede every other database out there) There is only one good reason I can think of for integrating the database into the O/S, which is that Microsoft eventually decided it was a bad idea to do so:-) Regards, Brian.
