That's the first question that you should ask yourself when looking at going outside of the datbase for persistent storage. I would imagine that the data is quite important, and unless you want to write all the necessary functaionality in your one-off data storage solution (which may or may not be slower than the a RDBMS or ODBMS solution) you should have a pretty good argument for why a real database should be used.
It sounds like you're working with a pretty uninformed technical staff, to be honest.
Drop the UML.... drop the "automated schema changes" and use normal, old fashioned oo --> database methodoligies. This whole fixation on UML and autotmated schema creation is just absurd, when its so easy to work with the database itself in sQL... and won't hamper your design. The managers at my old company loved UML and schema propogation... and were awarded with bloated, hard to understand code. (Thank God they had no say over my use of the database).
My 2 cents....
Slashdot Mirror
That's the first question that you should ask yourself when looking at going outside of the datbase for persistent storage. I would imagine that the data is quite important, and unless you want to write all the necessary functaionality in your one-off data storage solution (which may or may not be slower than the a RDBMS or ODBMS solution) you should have a pretty good argument for why a real database should be used. It sounds like you're working with a pretty uninformed technical staff, to be honest.
Drop the UML .... drop the "automated schema changes" and use normal, old fashioned oo --> database methodoligies. This whole fixation on UML and autotmated schema creation is just absurd, when its so easy to work with the database itself in sQL ... and won't hamper your design. The managers at my old company loved UML and schema propogation ... and were awarded with bloated, hard to understand code. (Thank God they had no say over my use of the database).
My 2 cents ....