Politics, Politics, Politics

An often heard argument is "How many non-relational implementations are really of a commercial scale?". This argument is about 15 years old and has proven to be an excellent innovation stopper. Remember object-oriented database in the mid-80ties? This industry has been killed off successfully and now all Java developers use an object-oriented language and talk to a, well, objectish database. At best. Many still use pure SELECTs and somehow manually map the results into objects. To most advanced students the idea to make objects directly persistent in the database is absolutely alien. Not cool.

So what about XML databases? Are they also only a temporary disturbance in the mainstream corporate SQL-centric universe? And should all full-text databases be imported into SQL stores? Probably not.

There is also a techno-political aspect to using SQL as the technological foundation for a TMQL. SQL is a moving target. It is not moving fast, but it is moving and when and how it does that is beyond the control of the TM community.

And there is also another, more serious angle to that. Forcing TMQL to be implemented on top of SQL engines only favours those database vendors which have implemented the necessary SQL machinery. And you can cut off a lot of fingers from your hands and still have more than this number of companies.

And even if we choose to do so, how many different implementations of TMRQL could then be actually done? One? What should I do if I have stored my topic maps in a Tamino XML database? Export it to an MS-SQL server first? Brrr :-).

Similar arguments also apply to the 'tool support' argument. Yes, there is tool support for SQL, and - cynically speaking - probably one needs that. I am increasingly sceptic when it comes to tools and development environments which help me to make something work. They only increase the distance between me and the problem and cause significant costs when environments have to be switched. This includes also the niceties like SQL query plan analyzers or debuggers. If I cannot understand it without tool support, then there is something intrinsically wrong. Tools are like crutches. They help you to limp along if you cannot walk on your own.

I would find it extremely unfair if an ISO standard would force TM developers into such environments; it will definitely put off most of the people I work with.