Re: TMQL Proposal

On 1 Feb 2005, at 07:10, Robert Barta wrote:

> On Mon, Jan 31, 2005 at 08:23:40PM +0000, Kal Ahmed wrote:
>> Actually I don't buy either the claim that the answers are complex or
>> that all of the TMQL use cases are simple.
>>
>> The queries presented in the paper mostly use simple JOIN or
>> sub-selects - bread and butter SQL stuff. We did use CURSORs in one
>> place and as noted in the examples we used DECLAREd variables only to
>> enhance the reading of the SQL.
> ...
>
> Kal,
>
> I would supports Lars' assessment of the SQL 'working knowledge' out
> there, and I would assume that even subselects blow 60% of the typical
> students out of the water.
>

1) Don't hire students to do a developer's work.
2) And how many students know tolog / AsTMa ?

> The SQL-familiarity-argument was brought up often in the past and got
> acknowledged to a point where TMQL will have some SQL-ish syntax
> flavor. And, yes, I know that it is difficult to sell to a CTO, that
> he will need a dedicated TM database engine, especially, when he tries
> to cut the cost by server consolidation and EAI. Therefore lots of
> people will try to implement TMQL based on a relational model.
>
> That works, albeit in an epicyclic manner: You cannot expect a
> general-purpose relational DB to be as effective than a dedicated
> one. You have a family waggon car?  Yes, then do not try the Dakkar
> Rally, but making holidays in Europe is ok.
>
> Why is Google not using a relational database? Or _any_ other search
> engine? Why is the publishing company next door not using Oracle, but
> a (still off-the-shelf) image pattern matching database?
>

And how much did they pay to develop them ? How portable is the 
knowledge of those systems ? How can they apply their pattern matching 
technique to other enterprise-level applications ?


> So, I would assume that implementing TMQL ontop of tables could be good
> enough for MANY projects, maybe not for all.
>
>>> Another problem is that although SQL-92 is a standard, few databases
>>> actually follow the standard, and so TMRQL would not provide
>>> portability. If we used SQL-92 we wouldn't need to define ORDER BY
>>> ourselves, but NULLs sort differently in different databases (etc
>>> etc), and so portability is compromised.
>>>
>>
>> That may be true, but the problem is well-understood. Also how do you
>> see the lack of consistent ordering across platforms being a problem
>> for anything but conformance tests - what are the real-world use cases
>> that demand this ?
>
> You do _not_ want the query language to do ordering, but the
> application should do this itself?
>

I was responding to LMGs point, but if you want to put sorting out of 
scope for the query language, then LMGs point goes away, doesn't it ?

>>> There's also the issue of what people who don't implement on top of a
>>> relational database (and there are some of those, and likely to be
>>> more in the future) should do. Requiring them to implement SQL-92 in
>>> its full glory doesn't seem too attractive.
>>>
>>
>> 1)  tolog is non-trivial to implement and is incredibly hard to
>> implement efficiently.
>
> First, I do not think that tologish languages are hard to implement.
>
> Secondly, whether tolog can be implemented efficiently cannot be 
> discussed
> without discussing how data is stored and represented. Implementing
> tolog over TMAPI might probably be very, very slow.
>

And your point is that implementing a new type of database system tuned 
to topic maps is in someway a less difficult task ? Sorry I don't see 
how this statement jibes with the one about specialising the data store 
for the task.

>> 2) How many non-relational implementations are really of a commercial
>> scale ?
>
> You mean except the DNS databass, LDAP? Nada, zilch. No OODBMS has
> ever made it into the mainstream, and no XML DB will do it in the
> foreseeable future. Most RDBMS vendors have incorporated OO'ness and
> XMLishness into their database. Yes, this is mostly an ugly hack.
>
> OTOH, how many "large" database vendors are there? MS-SQL, Oracle,
> DB2/Informix, Sybase, Postgres and MySQL/SAPDB. I count 6, worldwide.
> After 30+ years of RDBMSes?
>
> What is exactly the argument? That we have used the 1435 mm rail gauge
> for some time and that all vehicles are supposed to use it? That RDF
> content should be queried as if it were relational data?
>

Well, what is your argument ? That we should all be developing new data 
stores and a new query paradigm as well as trying to sell the topic 
maps meta-model ?

See you in 10 years when you have something you can sell to a CIO.

>> 3) We propose a system of relational views - I think that is the key
>> thing here. If you implement on an XMLDB it would make more sense to
>> simply provide the relational views (maybe using indexing features of
>> the XMLDB) and then use the underlying system's query language
>> (XPath/XQuery/Whatever) to do the queries.
>
> Don't you have here then not a double impedance mismatch?
>
>     Application -> Kal.SQL.Views -> XQuery?
>

Maybe so (I'm not convinced) - but its certainly going to get me from A 
to B going via C than trying to reinvent the wheel and the road.

Cheers,

Kal