RE: A DBA perspective.

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

	Actually, it is easier to agree on a Query syntax, than agree on a soda ;-)
Let us not get into soda wars - if so, we should have another soda working
group to resolve it. I am against the Registry group taking up more
responsibilities.

just my 2 yens

cheers

> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Thursday, January 11, 2001 10:05 AM
> To: Farrukh Najmi
> Cc: ebxml repository; Michael Rowley
> Subject: Re: A DBA perspective.
>
>
> Farrukh - I have a real problem when you make statements
> like this all!!!
>
> Well no surprises there ; -)
>
> For once its seems like we are actually saying the same thing -
> but just the terminology is the issue - when I say 'stored procedure'
> you are jumping to a specific implementation - where I am using
> the term generically to mean a 'blackbox' business function of
> the API.   When you talk about Objects I'm referring to reusable
> components.  Ok - this is like drinking Coke instead of JCola -
> there are both still sodas!
>
> What's this about OQL?!?  That's a specific query syntax
> however which way you want to slice it - and
> I thought we'd already agreed this dog will not hunt?  If its
> such a hugely available standard why is Oracle not supporting
> it?
>
> What's this about homebrewed syntax?  Hey - that argument
> can be applied to ALL the syntax so far developed for
> registry - its just something someone made up - and the
> only point is that it is using angle bracket markup called
> XML.   Containers for content.   If we are not allowed to
> ever do this because it is some kind of mortal sin - why
> is everyone else doing it?!
>
> OK - let's see if we can agree on sodas.
>
> See my notes below.
>
> Thanks, DW.
> ==================================================
> Message text written by Farrukh Najmi
> >
>
> I want to point out that stored procedures are an implementation
> detail. IN
> contrast the methods defined in RIM 0.54 (
> http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00086.html )
>
> used by the OQL approach are elements of registry specifications.
> It should
> be noted that the constrained OQL approach could be implemented to map the
> speced relationship methods in RIM to stored procedures directly (as an
> implementation choice).
>
> >>>>>>>>>>>  Ok - so why choose OQL at all?
>              If we stick to the highlevel we avoid
>              any query syntax specifics at all.
>              An implementor can then choose
>              whatever they please - at the level
>              of the API the backend query
>              syntax is not visible.
>
>
> In my own implementation I personally would stay
> clear of stored procedures based on a very long history of having
> implemented database engines as well as query processors. They are a
> maintainenec nightmare and are not implemented in a standard way
> across DBMS
> (one loses DB portability).
>
> >>>>>>>>>>> Exactly - so we define 'blackbox' procedure behaviour.
>             I'm not suggesting that you personally should
>             maintain every registry implementation on the
>             planet.  All we care about is consistent behaviour.
>             If I invoke getRegistryObject against two
>             different registries - I should get the same result
>             set - I care not what internal hoops they are
>             jumping thru.
>
> I would instead choose to define methods on implementations of
> objects (e.g.
> ManagedObjectImpl) defined by RIM to return a SQL query as a direct and
> simple mapping of the relationship method. The OQL processor would call
> these methods to resolve these methods calls to their equivalent SQL
> queries. It would then apply any simple global optimization over the query
> predicate and then simply pass the resulting SQL query to the relational
> database.
> >>>>>>>>>>> Overuse of the word simple.  You just told me
>             that writing code is a nightmare to
>             maintain - so why are you saying to write
>             SQL and OQL now?  Let's define those
>             methods of the objects and we are done.
>             We then state that implementors will
>             choose to map these to their own
>             query syntax as needed.  The
>             only common thread is that the
>             content exchanged is passed
>             inside of XML containers.
>
>
> The key difference in the 2 approaches being debated is that the
> constrained
> OQL approach is based on standards (SQL, OQL) and is familiar to use for
> most implementors, while the custom XML qyery syntax is a home
> brewed query
> language syntax that does not have the strength of years of experience,
> review and expert contribution that the former approach does.
>
> >>>>>>>>>>> OQL familiar?  So more people know OQL than XML?
>             XML does not have years of experience?  Farrukh
>             what do you think I've been doing for the past 23+
>             years?  Writing memos, making phone calls
>             and playing solitaire?
>
>             We need ad hoc querying that average end
>             users can handle.  Simple XML containered
>             API approach will reach more people easily
>             than requiring knowledge of a specific
>             query syntax - I don't care which one you
>             choose.
>
> DW.
>