Table Oriented Programming

I have written an article on in which i was able to write a domain specific language using SQL when the database is modelled using "Table Oriented Programming" techniques.You can find the article here.One notable advantage of this technique is that we do not have to write seperate parser/grammar to get a DSL,we just use TOP and SQL syntax.

I am not a TOP fanatic(ala TopMind), but have found the technique pretty useful at work which prompted me to write this article. Also note that this article was intended to be published in a magazine for general developers, so the terminology is a little loose.

However Corrections, flames and opinions are always welcome.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Maybe I'm missing something b

Maybe I'm missing something but this just looks like a fairly standard use of SQL - not sure I'd exactly call it a domain specific language?

I guess it may help to think about it that way sometimes, but personally I don't think using a query language on a particular schema feels desparately DSL-like. What's 'domain specific' about the language apart from the names of the relations and columns?

It is not a DSL as in a DSL t

It is not a DSL as in a DSL that passes an elbow test.Technically, it is not a domain specific langauge.
But for domain specialist programmer's it is a DSL.

The length of the article and intended audience prevented me from going very deep into the topic or using advanced features. I think you missed the point that the DSL feel you get is because of TOP.Not just relations.

Also, if u use advanced features(not always portable) features of SQL like stored procedures,functions etc. you get a DSL.

For example if you want to calculate a tax in the previous example i can write a stored procedure which takes the employee id as input. and the DSL query can say :

calculate_tax 5

where 5 is the employee id, which is a valid SQL construct.Doesn't this make it a DSL?

Isn't this just good programming

But what if I were to store the data as, say, Python objects. Then I could write a function to, say "add_tax_rate(state, rate)", and I could write another function to calculate the tax. And the "DSL" query can say:

calculate_tax(5)

The term "domain specific language" is usually applied to tools like make, lex, yacc, SQL, HTML, etc. Those all have a variety of syntax elements that are composable and distinct from the host language. (Notable exception: Lisp, where DSLs frequently let you use Lisp code as subexpressions. That's one of the main advantages claimed for it.)

This is a separate concept from the abstraction mechanisms that almost every major programming language has. It looks like you're advocating the use of SQL's stored procedures and English-like syntax as a "DSL". But this is a feature of every major language, and good code in any language usually tries to match the abstractions of the problem domain as closely as possible.

SQL vs. the external language

I've (unfortunately) done a fair bit of Java-with-Database work where the purpose is to write the 'business logic' in Java, and use the database as, effectively, and 'object store'. While things like TOPLink, JDO and Hibernate have worked out mostly OK (I have yet to get to use DB4O), it has always seemed pretty gross.

But even if there were no database, I think doing the business logic in Java, or Perl, or whatever, is generally not nice. Sure, there might be some form of job security, but on the other hand I would much rather have a great DSL to give to the users so I can get on with more interesting things in life. Thus, I found your article very interesting - it is always good to encounter new food for thought.

However... :-) A main advantage of a DSL in my mind is to have syntax that can be used by the less technical folks around. Admittedly, I could also possibly benefit from sundry DSLs, but I have to say that I'm a little skeptical of using SQL in all of its 'glory' (Honestly, I am a bit of a bigot against SQL - not foremost for the Manifesto reasons, although those are interesting to me, but, heck, most implementations don't even have a boolean type, and I haven't come across any good interactive debuggers in MySQL or Sybase yet).

With whom have you used this approach, and what reactions have you received? What do you personally see as its perfect niche vs. when do you think it is less applicable? (I know you have such sections in your article, but could you expand upon them? E.g.: do you feel everybody should learn SQL?)