Rel options in the future
Posted: Tue Mar 07, 2006 1:34 pm
I'm really quite excited to see this new DB being set up! I think it an excellent idea to start from scratch and avoid the compromises that SQL has forced on the world - I've always thought SQL an amazingly clumsy and old-fashioned construct, a bit like a modern COBOL.
I've quite a few questions about this really, and some ideas. Since there aren't many people here yet, I'll put them in one post rather than lots of different ones - feel free, of course, to discuss them in different threads if you're interested or find it useful!
1. I understand the decision to use java. It don't think it'll fly for an Enterprise wide system, no matter how java evolves. Maybe I'm wrong, but simply avoiding what you call 'sharp edges' is fine to start with, but means that they're just lurking there for later. What about starting a modular rock-solid re-write in Ada? That'd knock the socks off Enterprises in a few years time when it finally worked and be streets more solid than Oracle and the rest. If carefully designed it might even be faster.
2. When starting a new project, you can make bold generalising design decisions - or you can lock yourself into assumptions that make sense at the time, but limit your final results considerably some years later. Have these considerations and this design question been considered? I don't just mean being ready for 64 or 128 bit machines, I mean, for example, how adaptable is this model to a distributed DB? How well is on-line backup during normal operation designed into the Rel? How adaptable is Rel to multiple locking strategies being in place at the same time? How easily extensible is the set of language primitives?
3. I've been interested in database design (that is designing database engines, not designing databases) for over twenty five years. I haven't done that much about it, everything was well sqled fairly early on! How general is the object model, or could the object model be? Clearly objects need to include methods and many of these need to be standard, like existing DBs with their triggers and so forth. Could various Rel objects contain code for execution in different languages? Could, on the other hand, Rel insist on Ada (for example) being used to encourage consistent coding? Alternatively, are there sufficiently general rule models to enable useful objects to be developed?
4. Since this is early days, a couple more extreme questions. A distributed relational object-orientated db is a general platform model. How easy would it be to transform Rel into an e-mail server, for example, to compete with Exchange? How would object addressing, ownership, security, integrity and so forth be treated in such a distributed environement? Could Rel easily handle voice, video and so forth in the future?
5. Another application style question. If Rel were to be used as a document management system (or one of the many related things), how well would it manage (and how would it be designed to manage) the volumes, the need for versioning, secure storage and retrieval etc. etc.?
6. In designing db objects, has something like UML been considered? Could somebody design an application based on a future version of Rel by defining how the objects kept with in it are defined in time, space and ownership using something like UML so that it would be the basis of an Enterprise wide workflow engine?
Some of the above might well, at this stage, seem to you as quite irrelevant to the design or Rel and its implementation. I'd like to suggest that they aren't. If the design considers these possible uses at an early, design stage, then you don't end up with these things added as cobbled on extras later, you can build proper hooks, at least, for them early on and consider language extensions to include them.
Ok, so that is far too much to take on at the start, it probably all sounds like wild pipe-dreams now. But, is it worth at least thinking about these?
I've quite a few questions about this really, and some ideas. Since there aren't many people here yet, I'll put them in one post rather than lots of different ones - feel free, of course, to discuss them in different threads if you're interested or find it useful!
1. I understand the decision to use java. It don't think it'll fly for an Enterprise wide system, no matter how java evolves. Maybe I'm wrong, but simply avoiding what you call 'sharp edges' is fine to start with, but means that they're just lurking there for later. What about starting a modular rock-solid re-write in Ada? That'd knock the socks off Enterprises in a few years time when it finally worked and be streets more solid than Oracle and the rest. If carefully designed it might even be faster.
2. When starting a new project, you can make bold generalising design decisions - or you can lock yourself into assumptions that make sense at the time, but limit your final results considerably some years later. Have these considerations and this design question been considered? I don't just mean being ready for 64 or 128 bit machines, I mean, for example, how adaptable is this model to a distributed DB? How well is on-line backup during normal operation designed into the Rel? How adaptable is Rel to multiple locking strategies being in place at the same time? How easily extensible is the set of language primitives?
3. I've been interested in database design (that is designing database engines, not designing databases) for over twenty five years. I haven't done that much about it, everything was well sqled fairly early on! How general is the object model, or could the object model be? Clearly objects need to include methods and many of these need to be standard, like existing DBs with their triggers and so forth. Could various Rel objects contain code for execution in different languages? Could, on the other hand, Rel insist on Ada (for example) being used to encourage consistent coding? Alternatively, are there sufficiently general rule models to enable useful objects to be developed?
4. Since this is early days, a couple more extreme questions. A distributed relational object-orientated db is a general platform model. How easy would it be to transform Rel into an e-mail server, for example, to compete with Exchange? How would object addressing, ownership, security, integrity and so forth be treated in such a distributed environement? Could Rel easily handle voice, video and so forth in the future?
5. Another application style question. If Rel were to be used as a document management system (or one of the many related things), how well would it manage (and how would it be designed to manage) the volumes, the need for versioning, secure storage and retrieval etc. etc.?
6. In designing db objects, has something like UML been considered? Could somebody design an application based on a future version of Rel by defining how the objects kept with in it are defined in time, space and ownership using something like UML so that it would be the basis of an Enterprise wide workflow engine?
Some of the above might well, at this stage, seem to you as quite irrelevant to the design or Rel and its implementation. I'd like to suggest that they aren't. If the design considers these possible uses at an early, design stage, then you don't end up with these things added as cobbled on extras later, you can build proper hooks, at least, for them early on and consider language extensions to include them.
Ok, so that is far too much to take on at the start, it probably all sounds like wild pipe-dreams now. But, is it worth at least thinking about these?