4 ms·

Since SQL Server 2005, modern alternatives to the procedural components have been added to the product. Even with these features existing it does not make any

Since SQL Server 2005, modern alternatives to the procedural components have been added to the product. Even with these features existing it does not make any sense to call SQL a procedural language. Choosing the right tool for the job is certainly important. I notice many people write off SQL almost immediately when it is mentioned here. Often they come from a different language and do not see the value in the relational model. It's unfortunate too because there is real value in being able to go between a relational mindset seamlessly to an object oriented or functional one.

Pxtl 9y ago
I use SQL Server daily and I love the relational model. The core SQL language I dislike because it's verbose, backwards, and restricts sane forms of reuse. The procedural components of MS SQL are just plain miserable. I'm constantly frustrated that the two options in the database world appear to be "use SQL and all its anachronistic warts" or "give up on the relational model". NoSQL throws the baby out with the bath-water. But this is a tangent. The original post came about calling T-SQL a "procedural language". Which is inaccurate... but the author was talking about adding extensions to Sqlite - SQlite is already a SQL dialect. So if you're bolting on T-SQL to Sqlite, what's the main thing it will bring to the table? It's procedural components. So, in the context of comparing Sqlite to T-Sql, using the term "procedural language" might be a misnomer, but it makes sense here.
- electroly 9y ago
  Yeah, this is spot on. SQLite provides DDL and DML commands, but no support for composing programs from these commands. I leaned on T-SQL for the syntax and behavior of variables, basic control structures, procedures, error handling, and some common library functions, but that's all that it takes from T-SQL. I didn't intend to make a judgment about T-SQL, but rather to indicate which parts were implemented in SQL Notebook.
- ak39 9y ago
  >The core SQL language I dislike because it's >verbose, backwards, and restricts sane forms of reuse. I can appreciate the verbosity and "backwardness" argument you make, but can you cite some examples of its restrictions. (Serious question)
  - Pxtl 9y ago
    No algebraic types. No good way to query a graph of objects down, only a flat resultset. Infuriating performance problems if you layer views too deep or use scalar functions, which are sane encapsulation. No higher-level concepts of code reuse like templates. If I have a common pattern like "subclass table A by creating table B with a foreign primary key to A and create view vwB that has the combined columns of A and B" there is no SQL construct to express this common pattern.
    - ak39 9y ago
      Have you used T-SQL's "CROSS APPLY" or "OUTER APPLY" in conjunction with encapsulated views or table-valued functions? You might want to have a look at that as a significant enabler of code reuse on SQL Server. (On PgSQL is LATERAL JOIN) (Ps: you should try to replace SCALAR functions with SET-BASED logic. These can easily be ringfenced into TVF)
      - Pxtl 9y ago
        TVFs are intensely verbose to use compared to the corresponding SVF for a single column. Cross Apply will destroy your performance. I'm venting because I've watched clean, legible code get destroyed into soup of a zillion tiny joins and endless repeated boilerplate for performance improvement by this misfeature.
    - ianamartin 9y ago
      You just said to use the right tool for the right job, a few comments above. Everything you are saying here sounds like a job for something other than a relational database. I would shit a brick and beat any database developer with it that introduced the idea of a class as a primitive. Fuck that happy horse shit. Also, graphs? Really? You're looking for an ORM and blaming SQL for not being that. There is no common database pattern that creates one table as a subset of another table. RDBMS is, by nature and design, not something you modify in that way on the fly. If you want that kind of object oriented functionality, push your data into a cache layer or column store or KV. You said it yourself. Use the right tool for the right job. Nothing you've said makes even remotely any sense as a criticism of T-SQL or SQL in general. That's not the right tool for what you're talking about.
- deleted 9y ago
  [deleted]

Pxtl 9y ago

I use SQL Server daily and I love the relational model. The core SQL language I dislike because it's verbose, backwards, and restricts sane forms of reuse. The procedural components of MS SQL are just plain miserable. I'm constantly frustrated that the two options in the database world appear to be "use SQL and all its anachronistic warts" or "give up on the relational model". NoSQL throws the baby out with the bath-water. But this is a tangent. The original post came about calling T-SQL a "procedural language". Which is inaccurate... but the author was talking about adding extensions to Sqlite - SQlite is already a SQL dialect. So if you're bolting on T-SQL to Sqlite, what's the main thing it will bring to the table? It's procedural components. So, in the context of comparing Sqlite to T-Sql, using the term "procedural language" might be a misnomer, but it makes sense here.

electroly 9y ago
Yeah, this is spot on. SQLite provides DDL and DML commands, but no support for composing programs from these commands. I leaned on T-SQL for the syntax and behavior of variables, basic control structures, procedures, error handling, and some common library functions, but that's all that it takes from T-SQL. I didn't intend to make a judgment about T-SQL, but rather to indicate which parts were implemented in SQL Notebook.
ak39 9y ago
>The core SQL language I dislike because it's >verbose, backwards, and restricts sane forms of reuse. I can appreciate the verbosity and "backwardness" argument you make, but can you cite some examples of its restrictions. (Serious question)
- Pxtl 9y ago
  No algebraic types. No good way to query a graph of objects down, only a flat resultset. Infuriating performance problems if you layer views too deep or use scalar functions, which are sane encapsulation. No higher-level concepts of code reuse like templates. If I have a common pattern like "subclass table A by creating table B with a foreign primary key to A and create view vwB that has the combined columns of A and B" there is no SQL construct to express this common pattern.
  - ak39 9y ago
    Have you used T-SQL's "CROSS APPLY" or "OUTER APPLY" in conjunction with encapsulated views or table-valued functions? You might want to have a look at that as a significant enabler of code reuse on SQL Server. (On PgSQL is LATERAL JOIN) (Ps: you should try to replace SCALAR functions with SET-BASED logic. These can easily be ringfenced into TVF)
    - Pxtl 9y ago
      TVFs are intensely verbose to use compared to the corresponding SVF for a single column. Cross Apply will destroy your performance. I'm venting because I've watched clean, legible code get destroyed into soup of a zillion tiny joins and endless repeated boilerplate for performance improvement by this misfeature.
  - ianamartin 9y ago
    You just said to use the right tool for the right job, a few comments above. Everything you are saying here sounds like a job for something other than a relational database. I would shit a brick and beat any database developer with it that introduced the idea of a class as a primitive. Fuck that happy horse shit. Also, graphs? Really? You're looking for an ORM and blaming SQL for not being that. There is no common database pattern that creates one table as a subset of another table. RDBMS is, by nature and design, not something you modify in that way on the fly. If you want that kind of object oriented functionality, push your data into a cache layer or column store or KV. You said it yourself. Use the right tool for the right job. Nothing you've said makes even remotely any sense as a criticism of T-SQL or SQL in general. That's not the right tool for what you're talking about.
deleted 9y ago
[deleted]