Re: Object-oriented thinking in SQL context?

On 8 Jun, 18:25, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> dr.coff..._at_gmail.com wrote:
> > Hi folks.
>
> > I have a problem with wrapping my mind into the 'right' wrinkles.
...
> > Any general ideas on how to design a SQL database around
> > such constraints?
>
> > Dr. C.
>
> Those are mostly trivial data modelling problems. Have you read anything
> on data modelling, normalization, joins?

Yes, I have. Well, 'browsed' is a better term, as the objective is to get a working demo system up in a hurry. As age progresses, I'm more and more inclined to skip reading what is not immediately percieved as useful, so presumably I don't see the forest for the trees. Databases are the solution to the problem at hand; I just don't have the hands-on experience (yet) needed to come up with a working system.

The problem is that I think in OO terms, like classes and inheritance. Decades ago I used to work very hard to get away from arrays and other non-OO data structures associated with procedural programming, and now I am unable to revert my mind to that context.

In particular, I don't recognize OO terminology from what I read, and I am not able to recognize OO concepts from the terminology I do see. As somebody correctly pointed out, I am not used to the problem statement that needs to be used in DB design.

So in the 'naive' problem statement I see an array of objects of classes derived from a base class (in C++ I'd use boost::shared_ptr to access the objects), while I read that SQL is constrained to 'trivial' arrays. The problem is the vast philosophical distance between the two problem statements, that I am unable to bridge.

I'd appreciate any key words to look for when re-reading the material. I'm using Teorey's "Database Modeling and Design: Logical Design", 4th edition.

Dr. C. Received on Mon Jun 08 2009 - 19:06:31 CEST