6 ms·

> T-SQL, the procedural language I chose to implement atop SQLite, is not a great general-purpose programming language. T-SQL ( I'm assuming the microsoft vari

> T-SQL, the procedural language I chose to implement atop SQLite, is not a great general-purpose programming language. T-SQL ( I'm assuming the microsoft variant ) is not a procedural language, it's a declarative language. > Using C# in LINQpad is a more pleasant experience for experimentally messing around with data. This is not true. T-SQL is as close to the data as you can get. C#/LINQ/EF/etc are great for business layer/presentation layer. But for messing around with data, you can't really do any better than T-SQL. Trust me on this. If you are a front-end developer, then LINQpad is great in building .NET code/CRUD libraries/etc for dealing with data, but if you want to work with data, T-SQL is where it is at. Developing expertise in T-SQL ( it's not as easy as people think ) will open up a new way of understand data/programming/thinking. SQL Server allows importing of .net code/functions which you can run on the sql server via T-SQL so there isn't really much you can't do with T-SQL. > A local install of SQL Server Express can be linked to remote servers, allowing you to join local tables to remote ones. SQL Server Developer Edition is free now. That is a great starting RDBMs to learn databases on windows environment. It has almost everything other than enterprise level features ( clustering/replication/etc ) that most people don't need.

Pxtl 9y ago
> T-SQL ( I'm assuming the microsoft variant ) is not a procedural language, it's a declarative language. I think he's referring to the terrible terrible terrible procedural components of T-SQL - cursors, local variables, IF/THEN control blocks, etc. Right Tool For The Job. Sql is good for querying/storing data, so use it for that. Then let the C# handle manipulating the data and applying rules and whatnot.
- treebeard901 9y ago
  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.
- awkwardtortoise 9y ago
  > I think he's referring to the terrible terrible terrible procedural components of T-SQL - cursors, local variables, IF/THEN control blocks, etc. Sure. It also has stored procedures/functions/etc. But just because it has elements of imperative->procedural language doesn't mean it is a procedural language. No more than C#'s LINQ implementations mean C# is a declarative language or lambda expressions means it is a functional language. And though I'm not of a fan of cursors, it is a legacy of a time when it was somewhat needed. And nothing about local variables/controls/etc makes T-SQL "terrible". All of it is necessary for database maintenance, t-sql programming, etc.
  - Pxtl 9y ago
    > And nothing about local variables/controls/etc makes T-SQL "terrible". Compared to a full-featured programming language? It's good for its intent, which is to provide a minimal bit of procedural scaffolding for scripts that alter the database. It is terrible as a general-purpose procedural programming language, and I've worked with too much horrifying T-SQL and PL/SQL that pushes these tools way too far out of their intended workflow. Yes, T-SQL is predominantely a declarative language. But it includes procedural components for writing procedural scripts. And unless we're talking about maintenance scripts or deployment scripts, don't use them.
    - ianamartin 9y ago
      You just need to calm down. Everyone here has spent a certain amount of time dealing with shitty code. That's all you're really claiming here. That some people write shitty code. And I agree. I've spent plenty of time with almost every flavor of SQL code that was incredibly shitty. But I don't really blame the languages that much. I blame the people who didn't understand when and where to use one language or another. And frankly, if you're seriously going to complain about T-SQL vs other "more full featured programming languages" and then make a blanket statement about not using any procedural components on SQL flavors . . . ummm, you might be your own worst enemy here.
      - Pxtl 9y ago
- yawaramin 9y ago
  Manipulating data and applying rules are also something relational databases are excellent at.
- ianamartin 9y ago
  Or use the right tool for the job and use your database for manipulating your data, applying rules, and whatnot. Use your presentation layer for displaying your data once it's actually properly processed.
mistermann 9y ago
> but if you want to work with data, T-SQL is where it is at. Depends on your definition of "working with data" I guess.....TSQL is fast, but beyond that almost anything beats it for functionality when messing around.

Pxtl 9y ago

> T-SQL ( I'm assuming the microsoft variant ) is not a procedural language, it's a declarative language. I think he's referring to the terrible terrible terrible procedural components of T-SQL - cursors, local variables, IF/THEN control blocks, etc. Right Tool For The Job. Sql is good for querying/storing data, so use it for that. Then let the C# handle manipulating the data and applying rules and whatnot.

treebeard901 9y ago
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.
awkwardtortoise 9y ago
> I think he's referring to the terrible terrible terrible procedural components of T-SQL - cursors, local variables, IF/THEN control blocks, etc. Sure. It also has stored procedures/functions/etc. But just because it has elements of imperative->procedural language doesn't mean it is a procedural language. No more than C#'s LINQ implementations mean C# is a declarative language or lambda expressions means it is a functional language. And though I'm not of a fan of cursors, it is a legacy of a time when it was somewhat needed. And nothing about local variables/controls/etc makes T-SQL "terrible". All of it is necessary for database maintenance, t-sql programming, etc.
- Pxtl 9y ago
  > And nothing about local variables/controls/etc makes T-SQL "terrible". Compared to a full-featured programming language? It's good for its intent, which is to provide a minimal bit of procedural scaffolding for scripts that alter the database. It is terrible as a general-purpose procedural programming language, and I've worked with too much horrifying T-SQL and PL/SQL that pushes these tools way too far out of their intended workflow. Yes, T-SQL is predominantely a declarative language. But it includes procedural components for writing procedural scripts. And unless we're talking about maintenance scripts or deployment scripts, don't use them.
  - ianamartin 9y ago
    You just need to calm down. Everyone here has spent a certain amount of time dealing with shitty code. That's all you're really claiming here. That some people write shitty code. And I agree. I've spent plenty of time with almost every flavor of SQL code that was incredibly shitty. But I don't really blame the languages that much. I blame the people who didn't understand when and where to use one language or another. And frankly, if you're seriously going to complain about T-SQL vs other "more full featured programming languages" and then make a blanket statement about not using any procedural components on SQL flavors . . . ummm, you might be your own worst enemy here.
    - Pxtl 9y ago
yawaramin 9y ago
Manipulating data and applying rules are also something relational databases are excellent at.
ianamartin 9y ago
Or use the right tool for the job and use your database for manipulating your data, applying rules, and whatnot. Use your presentation layer for displaying your data once it's actually properly processed.

mistermann 9y ago

> but if you want to work with data, T-SQL is where it is at. Depends on your definition of "working with data" I guess.....TSQL is fast, but beyond that almost anything beats it for functionality when messing around.