If u are doing ur "normal" applications that as a rule of thumb can be stored in an excel spreadsheet, then traditional db is a way to go.
Biggest problem with an ODBMS is the lookup time of objects, but then again there is an addon, where u can catalog certain key variables, but then u kinda tie u kinda fall into the same problems u have with a traditional DB.
Where ODBMS shine.
Things like triggers etc, in traditional DB have no purpose.
Problem store an dom layout of an html page in an traditional database.
Also it depends greatly on how the language handles classes, with fixed class systems like delphi/C++ etc, you would have to make a base class and inherit a zillion elements off it.
Also if u decide to change the design of ur DB u are fuked, since u have to totally redesign the DB layout etc.
Because of the way python objects are setup, adding an extra field, method etc, is as simple as redeclaring the class.
And then reloading the class data into the new hash. If PHP is not designed like that, (as in objects/class are like thier delphi/C++ it is not possible).
A very simple problem where the wheels fall of a traditional DB.
Markov chain for generation of text (a tree like structure)
u have something like
class Person:
some data stored about person
class Student(Person):
xxxxx
class HouseWife(Person):
xxxxx
You then have a database population which stores all different type of people.
With a traditional DB u would have to try and figure out all the fields of the DB before hand before hand.
Here u can regardless store the person whether they are housewife,student etc serially.
If u decide to come up with new type of person like Doctor, no problem u just shove the object in.
Regular DB u are fuked, as u add more different types of people u have to create/redesign more different tables etc. Also tables do not inherit properly.
If u change Person, u can have a version field, if version 1, lazily upgrade it to version 2 etc
.
So lets say u have a new person doctor.
Here is where u have another database containing schools.
class Doctor(Person)
medicalSchoolsAttended[] <-- will contain reference to school object this will contain references to the school object.
You could also have a School with a list of graduates, which point to doctors.
No need to worry about circular references. It will sort itself out
If u make a change to any object it is propagated back to the database.
Also regardless of what traditional DB u use, u have to shove the results into some sort of local variable, object etc, this take processor time, adds complexity.
No need because the object in the DB and in memory is the same. (BTrees work on lazy loading, as in object is only loaded when needed, when reference to object is lost it is unloaded).
So even if with massive ammounts of preplanning u are able to create a traditional DB, that can hold different types of people,schools.
Lets say that dipshit who is having u design ur database, wants u to keep track of the vehicals that the person owns.
Back to the drawing board u go. U have to redesign ur entire DB.
ODBMS simple
class Vehicle:
owner -> field that points to owner
Just add to the person class 1 field vehicles [] (has to be array since 1 person can own many vehicle).
5 minutes work.
if dipshit wants to change vehicles to different types, as in small cars,medium cars, trucks buses what ever.
Just make the appropriate classes and away u go
