Dear Monks,

I have been watching a series of Advanced SQL lectures online.

Most my experience with SQL is with 1992 standards. I used T-SQL for MS SQL Server.

I'm quite impressed with some of the new functions of more recent standards. Others I'm not so sure about. It seems to me that much of the recent additional functionality could be achieved using simpler code, admittedly longer code (as was with SQL-92). Compactness of code seems to me to be unimportant relative to clarity.

Much could be achieved, I remember, interfacing Perl code with T-SQL. Is SQL in danger of running ahead of itself? Should SQL be contained and constrained? I kind of feel that much can be achieved using SQL, including class inheritance. But how far should the SQL ISO standards go with all that?

SQL is now a Turing complete declarative language, with a recursion capability.

Any thoughts on all that?


Update___________

My thinking has been that programming languages do not quite adequately consider the requirements of Agile methodology. This became clear when reviewing the recent implementations of SQL for the various DMS.
  • Comment on [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile?

Replies are listed 'Best First'.
Re: [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile?
by erix (Prior) on Jan 04, 2021 at 19:39 UTC

    Unfortunately the subject under discussion, SQL Standards, are not freely available. This makes discussing it a bit hard.

    https://modern-sql.com/ has at least some detail.

[reply]
Re: Have SQL standards gone too far?
by LanX (Saint) on Jan 04, 2021 at 16:41 UTC
    Hi

    I've moved it to meditations since it's an opinion piece.

    I'd also like you to edit the title and mark it (OT) for "Off-Topic".

    > Any thoughts on all that?

    I need examples or at least links to build an opinion.

    Your description reads rather fuzzy.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]
[d/l]
Re: [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile?
by Bod (Parson) on Jan 04, 2021 at 19:28 UTC
    do not quite adequately consider the requirements of Agile methodology

    Before contemplating if they do, it may be wise to question if they should.

    Agile methodology certainly has opponents - random example - and there is no clear case for why it should be universally applied to Perl, SQL or any other technology.

[reply]
      Agile methodology certainly has opponents - random example

      I'm not sure that article says what I think you're saying it says.

[reply]
Re: Have SQL standards gone too far?
by Bod (Parson) on Jan 04, 2021 at 17:14 UTC
    Any thoughts on all that?

    Adding extra functionality doesn't necessarily come at the expense of previous ways of doing things. I cannot think of anything I wrote in SQL 20 years ago that would not work now subject to being tailored to the RDBMS in use. Although, like LanX I'd need some examples to be able to properly comment.

    Compactness of code seems to me to be unimportant relative to clarity

    I don't universally agree.
    If it is a SQL query for a non-techie manager then sure, clarity is the priority. But the same isn't true for a query that is black boxed in a piece of code. Provided the creator and maintainers of that query understand it, nobody else need care about its clarity. Performance is probably the greatest concern followed by compactness.

[reply]

      The number one priority of those maintaining a DB system isn't performance or clarity, it's the integrity of the data.

      Extra code for clarity is extra code that can have bugs which can have an impact on data integrity.

[reply]
        I agree with your first line. However I don't quite agree with your second. My thinking has been that all too often programming languages have not adequately taken into consideration the needs of the Agile community. If you were developing an analytical database, for example, in a Agile way, then logic separation might be key to that process of incremental development. The more logic one puts into a single statement the harder that becomes. For me SQL is the obvious case in point. But the same may also be true for Perl code. Perl code development could be impeded by excessive compacting of code. I'm in no way criticising the Perl community. It is however something that maybe the designers of the language, SQL in this case, but Perl also, should consider. Am I right?
[reply]

Back to Meditations