http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
I've worked with several projects and all have they used a database centric design and it seems to work fine.
It seems that it's a new idea flourishing and now it seems fine but the value of it has yeat to be tested or am I wrong?
Object-relation impedance mismatch is to do with the difference between relational databases and object-oriented software models. If you don't see any mismatch, it's because your code isn't really doing OO properly.
When you start doing OO properly, and trying to map those relationships to an RDBMS, you'll understand the problem.
The idea of an object-relational mismatch comes from the problems that arise when you try and use an object-oriented programming approach backed by a relational database. The problem arises from the fact that object models typically contain hierarchies of objects which need to be shredded into and rebuilt from multiple tables, rather than storing the object as a whole.
However, the argument that normally comes up at this point is that if you haven't found a problem then it's your fault because you're not doing 'proper' object-orientation, and that you'll find the mismatch when you learn to do object-orientation 'properly'. And we all know that object-orientation is the only 'proper' development paradigm.
Oh, wait.
Many systems do not suit being modelled as object-oriented systems. In fact, for things like web applications which tend to have overall low complexity (with localised high complexity) and require high concurrency and scalability, using service-oriented and message-passing techniques can be a better option. When an application is written in this way, you tend to find that there isn't too much of an object relational mismatch because you don't use things like lazy loading and complex object hierarchies, and your objects are immutable so they don't need to be shredded back into the database.
So is there an object-relational mismatch? Yes, if you try and use object-oriented techniques with a relational database. But you can mitigate it by not using object-oriented techniques, if other approaches suit your application better.
If your domain model is simple, and has no deep inheritance, you may never feel the impedance mismatch.
As an example, let's say class Foo defines property foo. Bar subclasses Foo, and introduces a property bar. How do you store Foos and Bars in the database?
You could have a table Foo that contains fields foo and bar... and every Foo will satisfy "bar IS NULL". But if your subclass introduces a whole bunch of properties, that's wasteful.
So maybe you have TWO tables Foo and Bar. Do you copy all the columns in Foo into Bar so you can load an entire Bar in one SELECT? Or do you have to JOIN Foo with Bar to load a Bar?
The impedance refers to the fact that you have to think about all these little details of how you "shred" (to use Greg Beech's term) an object into one or more tables.