Re: Object-oriented thinking in SQL context?

On 9 Jun, 08:49, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> dr.coff..._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?
>
> > Yes, I have. Well, 'browsed' is a better term, as the
> > objective is to get a working demo system up in a hurry.
>
> Define 'working'.

A demo system based on databases where some basic functionality is up and running, to demonstrate how to solve administrative tasks that are handled manually these days.

The techies are asked to keep track of the instruments, and somebody somewhere else do occasionally want to know the status of the inventory or calibration data for some operational instrument. I'm sure you'll get some impression of the problem from the sketch in my first post.

Instead of making a phone call ordering the techies to dig out that info manually and send back by email, my goal is to get a skeleton MSAccess database and MSExcel interface up to demonstrate how those who want to know can get the info without requiring manual interference from other people.

Everybody are happy and time-wasting stress factors are removed.

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

I know. But I'm doing this on my own, and am just starting out. I have a few books lying around that I need to make sense of. Naively, I thought asking experts for help would be useful.

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

Well, my basic programming training (I'm not a programmer but a data analyst by vocation) was in terms of assembler-style GOTO constructs and procedural programming. After a while I found that these styles or models were far too limiting for the types of problems I worked at. I had to make a serious effort to learn OO in general and C++ in particular. These days I think in terms of class hierarchies and policies.

Your name and location suggest your native language is English. If correct, you likely do not know a second language very well. Bilingual people will know that different languages tend to be useful for expressing different things. My native language is not English, but all my professional training was in English. Which has had the effect that I am unable to think about professinal questions in my native language. I find that I always refer to English terms when discussing work.

OO and policies has had the same effect, and have worked well enough that I haven't needed to look back. Until I encountered databases and SQL.

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

Ever heard of a 'class'? 'Supertype'? 'Specialization'? Teorey uses UML to communicate problems and solutions in the context of databases. Just as lots of folks do with OO programming. The concepts are the same everywhere. Terminology differs.

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

Yes, philosophy. It seems you are young enough that your basic training was in terms of OO concepts. I can assure you, when your basic training is in terms of procedural programming, the transition to OO is one of philosophy.

> An n-dimensional relation of arbitrary domains is 'trivial'?

No. The individual tables are trivial, not the overall relation. This relation is essentially the philosophical difference I was talking about: Procedural programming can represent anything the OO model can (as I understand it, OO programs are implemented as procedural constructs) but the details are understood by human users in different ways.

Complex relations, that are trivial for the human to comprehend when expressed in OO terminology and concepts, are not at all so when expressed in terms of basic data structures like tables and arrays.

This is the philosophical difference some of the posters here seem not to understand but nonetheless are gloating about - like in the 'laugh of the day' a couple of days ago: What database professionals and experts take for granted is at least percieved as at odds with the basic training of general-purpose computer practitioners like myself.

Referring back to natural languages, it is a very humbling experience to arrive in a place where you have no language in common with the natives. One is essentially set back to the level of a toddler, struggling to interact over the simplest things. As English becomes more and more wide-spread, native English-speakers would not have this experience.

Now, it makes no sense to mock people who ask about databases because they do not know English. It makes no sense to mock people who want to get help with basic terminology because they do not know basic terminology.

The database community can handle this in a couple of ways:

1. Close in on yourself and mock people who do not have the insights you have.
2. Recognize the problem and help sort out the misunderstandings and snags.

Over the past couple of days I have got a clear impression about what approach seems to be preferred by the regulars here.

Dr. C. Received on Tue Jun 09 2009 - 14:28:55 CEST