Re: Object-oriented thinking in SQL context?
Date: Tue, 09 Jun 2009 03:49:30 -0300
> 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.
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