> Interesting project related to these questions: > > http://sourceforge.net/projects/prevayler/
Some of the sentiments echo mine : "every transaction is represented as a serializable object which is atomically written to the queue (a simple log file) and processed by the system. An object, or object graph, is enough to encapsulate the complexity of any business transaction." Which is fine and dandy, but I think unrealistic in many circumstances. Serialising a whole transaction won't get you performance for a loaded system. In fact, may not be possible at all. I need to have a look at some of these ideas. > Annoyingly enough, I have two projects that need ready-to-wear database > stuff at the moment; one requires a minimal data store that can handle > indexing and multiple writers. The other needs to be a hierarchical data > store, and may require full text searching in the future. I'm trying very > hard to push these features away onto software that can handle them, but > separating the data is going to prove troublesome (I will probably have to > lock resources in a server in front of all this data shenanigans). Crazy > stuff. I can't recommend the book 'Managing Gigabytes' enough if you think full text searching is a possibility. It is a huge jump from RDBMS. You may be able to do a hybrid - DBMs for some parts, and a static text search system that is updated "off line" periodically e.g. overnight, hourly ... Although Postgres and MySQL seem big, they do a job superbly well. If you have a good hammer and you need to drive a nail don't start using the heel of your shoe! I also like this line : ``The terms "ANTICLIMACTIC SIMPLICITY" and "ANTICLIMACTICALLY SIMPLE" are hereby placed in the public domain.'' ANTICLIMACTIC SIMPLICITY is an oxymoron. When an author mixes oxymorons with buzz phrases like "serializable objects" and "business objects" I get worried. Jamie -- SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
