Recently I have read (in a PDF document - SQL for dummies) that SQL is actually a data sublanguage and not a programming language like C++ or Java or C# and right now I am a bit confused, because since you can develop things through SQL, I thought it is similar to other programming languages.
Could anyone explain to me what is the difference? Thanks
Try to write a simple but non-trivial application using nothing but standard SQL that asks the user to input their name, and outputs "Hello, ."
Maybe you could do it with some vendor-specific extensions, but then it wouldn't be standard SQL.
SQL is designed to be a domain-specific language for database queries. It's meant to be used in combination with a more fully-featured language. The SQL standard defines ways that you can write lines of SQL within the code file of C, C++ or other languages. There's no standard way to write a full standalone app using just SQL.
Read the standard. The SQL/PSM part defines a full-blown programming language with loops and IF-THEN-ELSE and what have you. SQL/PSM was initially amended to the existing standard in 1996 and formally included in SQL:1999.
As Bill Karwin hinted at, SQL does not have features for UI interaction, but then the very same thing is true about the java language (no, the swing package is not part of the language), and the COBOL language, and the ALGOL language, and many many others.
SQL began life as a data sublanguage. That history is >20yrs behind us. (The "data sublanguage" portion is still the most-used and most-useful part, but that does not change the fact that technically speaking, SQL-the-language has everything it takes to be regarded as a full-blown programming language.)
According to wikipedia a sublanguage
the term "sublanguage", first used for this purpose by E. F. Codd in 1970, refers to a computer language used to define or manipulate the structure and contents of a relational database management system (RDBMS). Typical sublanguages associated with modern RDBMS's are QBE (Query by Example) and SQL (Structured Query Language).
that means that sublanguages cannot be used to develop a standalone applications but they could be incorporated with other computer programming languages to manage the application-database interaction.
Standard SQL can only be used for defining database schemas and for querying and updating data. Database vendors have extensions to SQL (like Microsoft's T-SQL) that are full-blown programming languages.
Related
I'm trying to gain a deeper understanding of SQL, and I was just wondering - what was SQL originally written in? I did some research, and according to this stackoverflow page, it seems that SQL was originally written in C. If so, is there any way I could access the original source code to see how SQL really works under the hood - its algorithms, data structures etc? If SQL was indeed written in C, its inner workings must be imperative since C is an imperative language, and since I am more versed in C++ than in SQL, it would be really rewarding to explore SQL in terms of an imperative paradigm. Thanks in advance for any insight you may have!
SQL is a language definition, which itself is not written in anything but plain text.
Also, you can implement a compiler/engine for SQL or Java or whatever high level language in C++, C, Assembly, or even directly in machine code if you like, so the language in which it is implemented doesn't tell you anything about its possibilities.
Which SQL? There are a lot of different competing SQL database flavors out there: Sql Server, Oracle, MySql, PostgreSQL, Access, SqlLite, Sybase... and that's just the tip of the iceberg. Fortunately, several of those are open source... you can go look at the code for yourself.
You can also read the Sql Language Specifications.
Is there any database technology comparable to the SQL CLR?
Specifically, one that allows me to code high-performance routines in a common programming language like C# with shared memory (e.g. static variables) that can be called directly from within an SQL statement?
Not really.
More specifics about what you are trying to achieve would help.
There may be a flaw in your design / approach.
If you need to code high-performance, functional routines, they should probably not be embedded in your database. You should be implementing a middle-tier and placing your routines there instead.
I'm looking for good SQL parser. One that will work with subselects, non-select queries, CTE, window functions and other legal SQL elements.
Result would be some kind of abstract syntax tree, that I could later on work on.
Language is mostly irrelevant, as I am willing to learn new language just to use the library, if it exists.
I know that it is technically possible to extract parser from some open source database, but it's far from easy (at least for the parser of PostgreSQL which is what I need).
There's a non-validating SQL parser in Python: python-sqlparse. The tokens are exposed as objects. I doubt if they support "other legal SQL statements", window functions, and the like though as those are controlled by vendor specific grammars and no vendor is technically fully compliant with SQL standards.
Um (knowing that you're willing to learn a new language), why would you need to work on the syntax tree? If you need some magic in dealing with the database, probably you don't need to reinvent the wheel: Python got a fantastic database toolkit - SQL ALchemy.
You can google "sql parser". This is the one that listed: General SQL Parser Here are some highlighted features listed on official website:
Offline SQL syntax check
Highly customizable SQL formatter
In-depth analysis of SQL script
Fully access to SQL query parse tree
Custom SQL engine for various databases
Major programming language support
It's a commercial SQL library.
Our DMS Software Reengineering Toolkit has PL/SQL and ANSI SQL 2011 full parsers (to ASTs) and prettyprinters (ASTs back to valid text). Neither of these are PostGres SQL, but DMS has a dialect mechanism that enables one to relatively easily build a dialect from a base grammar, by revising just some of the grammar rules and retaining the rest. Doing this from the SQL 2011 grammar seems like a practical way to tackle the problem.
DMS also offers facilities to access/traverse/modify the ASTs, both procedurally and in terms of surface-syntax patterns and transformations. Think of this as "life beyond parsing".
I'm looking for a SQL Implementation (and its Editor) that can be used for translating it to many other(s) SQL Languages.
For example, when i code in that SQL Language to script file(s), and then i translate to other(s) SQL Language script file(s) (for ex: MS SQL's , MySQL's , ...).
If you're sure to use only ANSI SQL to construct your scripts, you should be good to go.
I agree with #Justin Niessner: all SQL vendors pay attention to the SQL Standards, notably core SQL-92. To take SQL Server as an example, although they find Sybase legacy code is tricky to deprecate they are not afraid to do so and entirely new features (e.g. MERGE in MSSQL2008) tend to extend their Standard SQL equivalents, rather than reinventing the wheel.
For a product that has good Standards compliance, take a look at Mimer
Here at Mimer Information Technology, we pride ourselves on conforming
to the SQL standard and we play an active role in the Database
Languages standardization group which determines exactly what is SQL
standard.
Mimer also provide extremely useful SQL validators for SQL-92, SQL-99 and SQL:2003 respectively.
I've been researching the same thing a while ago. What I've found is that there is a project liquibase. It is aimed at change tracking but also converting between different DBMS. You can download source code and see different datatypes conversions across databases. Source at github browse for java files there, probably you'll find something helpful
If all you want are basic operations, these are fairly universal. For instance:
SELECT
INSERT
DELETE
UPDATE
FROM
WHERE
JOIN
...are all at the most basic level the same across implementations.
However, the more complicated your scripts get, the more difficult it becomes to make them "universal". Things like aggregation, subqueries, cursors, while loops, functions, indexes, constraints, temp tables, variables, string manipulation, window operations etc. are all pretty much database-specific.
Some of these do have "universal" equivalents but the more generic you make your code the worse it will perform.
This topic is somewhat related to this question. There my answer was motivated by the assumption that SQL is necessary to access data in every database I know.
AFAIK, whether you are directly accessing data with some dbms client or you are performing a row-by-row operation (i.e. cursor) with some program (c++, java, cobol, whatever) using some db connector, you need, at some point, to write some SQL to actually read/modify data.
Now I'm asking: is this true in general? Is there any RDBMS that does not rely upon some SQL dialect?
I know that SQL is (not strictly) based relational algebra, which is the foundation of the relational model by E.F.Codd (1970).
So what I'm asking is also: is there any RDBMS that give a better implementation of the relational model?
The D language (Date and Darwen) was created as a relational language, and one of the first things they rejected was trying to make it match up with SQL.
There are several implementations (Rel, D4, etc) of D, but I'm not sure how tested these are in real, commercial settings.
You could look at the DEE project by Greg Gaughan, and the Alf project by Bernard Lambeau. Not necessarily genuine DBMS's (Alf is just the algebra, and offers no updating facilities).
The TTM website (http://www.thethirdmanifesto.com) lists all the projects that are inspired by it (and of which the authors are aware, of course).
BTW I like that double negation in your question.