4 ms·
Can someone describe the NEGATIVE aspects of having a database-OS?
by kensai 7y ago
Can someone describe the NEGATIVE aspects of having a database-OS?
- simonh 7y agoFirst enumerate all of the constraints and guarantees your database provides. All the basic minimum services it provides for every access. Look at the memory it takes to provide those, and the processor utilisation overhead to perform all those checks, and services such as to guarantee ACID compliance, guarantee referential integrity, enforce a global type system, etc, etc. Every single access of every single piece of data, for anything, will incur all of those overheads every time. There is no way to opt out or choose a different balance of guarantees or trade-offs without implementing them on top of the OS provided ones.
- twhitmore 7y agoYou're describing the fact that OS apis are typed, and check state for validity. That's already the case and OS system calls already incur those costs. In a database, preparing a query compiles the access plan (ie all the above) on the server side. There's no reason it would be any less efficient than an OS call today. Could in fact be more efficient, since you would probably be able to leverage set-based operations on the server (ie OS) side rather than iterating everything on the caller.
- simonh 7y agoIf OSes are already doing all these things, to the same degree required, and with the same overhead of a DB based OS, why do we need a DB based OS? What more is it giving us, and how is it providing that at no additional cost over the current model? 'On the server side' isn't magic. You don't get server side operations for free and these 'server side' operations would be occurring on the same computer.
- ken 7y agoEven my database doesn't incur all overheads for every operation. I don't know why an OS designed around the concept would. It's interface, not implementation.
- joveian 7y agoIt makes the conceptual model of the OS more complex. Filesystems with basic permissions are easy to understand becuse of the forced structure. IMO, ACLs are a bad idea for the same reason, they make it harder to see what is going on while not solving a problem I actually have. I guess they do solve problems that some people have so that makes them more attractive if you are one of those people but IMO there must be better ways to solve those problems. Personally, I'd like to see version control and file compression integrated in my filesystem. I do not want my operating system to be distributed or rely on network access. I also think a separation between administrative access to the full system and views of applications may be a good idea. It seems to me that the ideal OS would heavily restrict the file and network access of applications and there would be a separate administrative domain with full access but limited complexity. The operating system then manages the sharing of needed data between applications and network access that the user allows. I think having the system parse a standard configuration file format for applications would make sense in this model, but that configuration file can still just be text. Also having a sub-user permissions structure similar to the overall system users seems like a good idea to me. Many applications that users run are hostile and dealing with that requires major changes vs current desktop operating systems. Database vs. filesystem is a minor issue in comparison and personally I don't see the appeal of using a database.