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

Hi,

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?

Thanks,

Mike

Mike Angelastro, Aug 12, 2010

Reply 1

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,... nah...to 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.

Regards,
-Chris.

Christian Jacob, Aug 20, 2010

Reply 2

I think what you are looking for is an ORM product. Check this example: http://en.wikipedia.org/wiki/NHibernate

Pankaj Mhatre, Aug 13, 2010