3 ms·
I think marcosdumay already explained it pretty well. > I would have described SQL as statically typed because columns are given a type when created. Both sta
by js8 10y ago
I think marcosdumay already explained it pretty well.
> I would have described SQL as statically typed because columns are given a type when created.
Both statically and dynamically is a misnomer because it's akin to something more in-between - like a dynamic language which can create, say, an empty list and declare it can only contain integers.
Just quickly though - I believe static typing helps productivity, because you don't have wait for some edge case in your program (in this case infrequently invoked query, since SQL is often embedded in other language) to fail. There are other benefits, like Quickcheck.
I think better term (which would explain the distinction between schema creation and query compilation) would be static typechecking of queries against the schema.
> The issue arises with multiple tables
In general, SQL is quite adhoc in what it lets you do, and anything more complicated you need to resolve with code generation (for example running same query over different tables). It's very hard to reuse SQL code. That's ugly, and functional languages offer a better solution - high-order functions. I think what I really want is to deal with schema (and other things, such as result set) as first-class types.
I think the language should be functional, but also total (every function will finish, no recursion allowed), to make it easy for compilers (query engines).
- laumars 10y agoIt really depends on which RDBMS we are talking about. sqlite is definitely not statically typed. Values in cells can be compared against integers or strings using any preferred operators. However others relational databases such as Oracle support are strict about data types and even support inlining functions inside SQL (technically it's PL/SQL rather than ANSI SQL) for code reuse exactly like the feature enhancement you were describing. Most enterprise RDBMSs I wouldn't say we're dynamic; you define your table at the start of your code, Inc storage types (like you would declare global variables in a strictly typed imperative programming language) and you get compile time errors when executing the SQL if the datatypes are mismatched, just like you would in most modern strictly typed languages. The problem people typically raise about SQL is really more a matter of tooling. eg there isn't much in the way of Visual Studio or IntelliJ for SQL. The best I've used is MySQL Workbench but even that is buggy and often crash prone. However most developers generally write code outside of an SQL IDE because they're either inlining their SQL inside another language (eg via paramatised SQL functions in Go, PHP, Java or whatever) or a DB guy so skilled enough to write their SQL outside of an IDE (much like how some functional or imperative language developers use text editors rather than IDEs).