Database Structure vis-a-vis OOP/OOD and Design Patterns

65   95.6
Aug 12, 2010

Is there a way to design a SQL database so that it's very amenable to OOP/OOD and design patterns? For example, say your app is to have an employee class that is to inherit a person class.  Is it best or at least recommended for the back-end database to have a person table and an employee table with a foreign key to the person table.  Basically, I'm asking if there's a best way to design a SQL database in order to make it as easy as possible to write OOP apps based on it?



100   96.6
Aug 13, 2010
I think what you are looking for is an ORM product. Check this example:
 1 comment
Hi Pankaj, Thanks for replying to my question. I guess it depends on what comes first, the database or the OOD. NHibernate appears to be for situations where the OOD comes first. I was thinking that it may easier to design the database first so that the OOD mapping is easier. After all designing a database involves entities - another term for “objects” - with properties and relationships. Each entity or object would have its own table and the relationships among them would consistent with ‘is-a’ and ‘has-a’ requirements. Is such a thing possible? Also what if the database already exists? It may or may not be well designed. Thanks, Mike --- Mike Angelastro  Aug 13, 2010

555   99.9
Aug 20, 2010
Hey there!

Good question! It shows that there is a way, a developer thinks about databases that miiiight be different from the way, a database administrator thinks about it.

For example: You think in an object oriented way whilst a database administrator thinks in a structured, more relational way of storing data in an efficient manner. This is why he will always try to create schemas that reflects fully normalized table structures, foreign key constraints and that sorta stuff.

However,... this will result in people like you to think about what the hell might be the best way to transform the data in a way that allows you to work with it in your environment, i.e. an object oriented - and more over - type safe way. This is where Object Relational Mappers come into play.

No matter what they are called, NHibernate, EF, Linq2Sql,... hell with it: Maybe even Strongly Typed Datasets: They all do the same: Allow you to work object oriented with data.

If you don't want that, the answer is simple: Don't use a relational database. There are plenty of other fish in the sea... just have a look around and check object oriented databased.