Re: Object-oriented thinking in SQL context?

dr.coffee1_at_gmail.com wrote:
> 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?

Define 'working'.

> 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.

Hands-on experience is no substitute for fundamental education. If we had to rely on hands-on experience for multiplication, I doubt anyone would have ever progressed beyond the 12 times tables.

> 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.

Am I hearing you correctly? You worked very hard to force your brain to think in terms of a single physical computational model? That's unfortunate and must be very limiting. No doubt you will have to work equally hard to overcome that impediment.

> 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.

I am not sure what use you would make of OO terminology. It's all rather nebulous, overloaded and imprecise. None of it is any good for communicating much of anything.

> 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.

Philosophy? An n-dimensional relation of arbitrary domains is 'trivial'? And all these years I thought the number of golf balls on the moon was trivial.

> 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.

Keywords? Introduction, preamble, prologue, chapter 1. I would start with one of those. Not sure which terminology Teorey uses in the 4th edition, but I am sure you will find something suitable shortly after Table of Contents. Received on Tue Jun 09 2009 - 08:49:30 CEST