The Berkeley DB is incredibly robust and scalable and is in use transparently in millions of places across the web. GoogleMail login is authenticated via it, Amazon customized pages make approximately 800 calls to it, per instance of every customized page rendered!
Here's our thought process in determining to use Oracle Berkeley DB XML:-
- we aimed to use the Berkeley DB for its performance and extensibilty
- it's kind of embedded within the app and doesn't need a specific server or DBA facilities (great since IAB is not the real backend policy admin system)
- the primary reason is that it allows the application to work with the data in a way the application understands the data, i.e no specific mapping needs to figure in the app
- so we need to create a wrapper for an XML usage cos that's what our app understands since XML is being used down the stack
- so creating a wrapper is one of our project tasks
- oh..there's already a wrapper that might work for us…thank you Netscape for the XML layer requirement and to Sleepycat for incorporating, and responding to the Netscape need!
- gosh that might save us a shit load of time
- and also the wrapper is now supported by Oracle
We use Oracle Berkeley DB XML because we were looking for a agile storage repository capable of holding of holding millions of insurance policy details, each containing different types of insurance product data.
To model a typical commercial insurance product in a set of normalized tables can lead to an additional 50 - 100 tables per product. Meta programming the repository with Oracle Berkeley DB XML seemed ideal since XML was the linga franca of our whole stack!
We have a basic active_record adapter for sleepycat that allows use to follow the standard rails patterns.