Re: Object-oriented thinking in SQL context?
Date: Tue, 09 Jun 2009 14:26:44 -0300
Message-ID: <4a2e9b57$0$23768$9a566e8b_at_news.aliant.net>
dr.coffee1_at_gmail.com wrote:
> 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.
That seems to define 'demo system', but I see nothing there to define 'working'.
> Everybody are happy and time-wasting stress factors are
> removed.
Your definition of 'working' appears to revolve around happiness and stress factors. Would it make your customers happy to discover their data are incomplete, incorrect, or inconsistent? If those sorts of things would stress them or waste their time, I respectfully suggest you would do them a service by educating yourself first instead of seeking to learn by making mistakes.
>>>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.
I am not sure whether naive is the right word. It seems to me you have been given very useful help, and the problem originates in your insistence that your uninformed preconceptions can dictate what is useful or helpful.
>>>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)
How ironic. What studies did you complete to qualify as a data analyst?
> 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.
Well, I can certainly see how moving from an even lower-level computational model to another physical computational model would seem like a great advance.
> 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.
Dijkstra noted the advantages of coming to programming with english as a second language.
> 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.
The problem is you haven't yet realized that databases (and even SQL as flawed as it is) require looking forward not back from your current position.
>>>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'?
Of course. I wouldn't make statements about nebulosity, overloading and imprecision if I hadn't.
> 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.
UML borrows heavily from ER, which itself was a misguided attempt to create a graphical crutch. Graphical analysis often misleads and hinders understanding by fostering preconceptions. You will do yourself a great service to learn to think without that crutch.
>>>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.
I was programming quite extensively in a variety of languages for 5 or 6 years before I was ever exposed to an OO concept.
OO certainly has a slightly different aesthetic from other computational models, and of course, linguistic differences fall under the philosophy of language. Logic is still pretty much the same, however. And the relational model has much closer and deeper association with logic. It has in fact contributed quite a lot more to the topic.
>>An n-dimensional relation of arbitrary domains is 'trivial'?
>
> No. The individual tables are trivial, not the overall relation.
A table is an n-dimensional relation of arbitrary domains.
<elaboration based on false assumption snipped>
> 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.
It is even more humbling to arrive in a place that nominally speaks the same language as oneself and to discover on cannot make out a word anyone is saying.
> 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.
I am sorry you feel mocked.
> 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.
Interesting. What if one recognizes the problem is a simple lack of fundamental education? What if the misunderstandings and snags spring from a newbie's false but deeply ingrained assumptions? Received on Tue Jun 09 2009 - 19:26:44 CEST