On Sat, 2005-06-25 at 15:51 -0700, Asif Lodhi wrote: > Further, I worked with Oracle 9i database about a year ago and the > database server had the functionality to hold a particular (most > heavily used) part of the database completely in the memory (I am > talking about the in-memory database).
That's pretty typical, though I expect Oracle offers the admin more control over it than most do. > Though I haven't used SVN yet > but I do know that its data store is based on "Berkley DB" which is > also being used by MySQL now which (MySQL, that is) also supports > in-memory databases. Regarding bdb: *hiss* *spit* . There is no other piece of software that has caused me more problems and data loss as a sysadmin. Recent versions can be very reliable if built with transaction support and if the apps use that transaction support, but some distros even now build BDB without transaction support. BDB is also very vulnerable to issues caused by even small corruptions due to disk issues, hard poweroffs in the middle of a write, etc. BDB can work great, but it's really hard to get right. The 700 page book on the shelf behind me - the Berkley DB manual - reinforces that view ;-) I think Berkley DB is a fantastic tool for keeping a working store of data, so long as you keep the data in another format (presumably one harder to edit on the fly, etc) somewhere else. SQLite seems to be showing up more and more as a potential alternative to BDB, and I find it more attractive myself. One advantage of using SQLite is that if you need "bigger" DB functionality later, or need to hook into a db like oracle or PostgreSQL with proper concurrent transaction support etc, you can do so much more easily. I do think that however it's done, putting the Scribus file into a database and using the database's concurrency and locking features would be an interesting way to do multiple-user editing. A *huge* amount of work, I think, but potentially saner than most of the other approaches I can think of. Whether each copy of Scribus would talk to the db direct, or whether they'd use a "scribus document server" that knew all the db specific bits, I don't know. The whole document-in-database thing isn't a new discussion. Like most of the things discussed here, what we really need is someone to say "I have the time and skills, or the time and am willing to learn the skills, to do this. Where do I start?" These folks, alas, do not grow on trees. > So, don't you think Subversion's "Berkley DB" > data store could be modified/configured to hold everything (DTP/.sla > files, that is) in-memory to keep the disk-contention to the minimum? Berkley DB is from SleepyCat software. It's only relationship with svn is that svn uses bdb. The more recent versions offer the option of a flat file store as an alternative because so many people just wouldn't trust bdb (myself included), too. If a doc-in-database scheme was implemented, I suspect it'd be better done with a "scribus doc server" to mediate requests and hide database implementation specific details. With that, the database back end could even be made configurable, and bdb would be one option to investigate, yes. -- Craig Ringer
