I am new to DB technologies. And now I have reached such concept as procedures and PL/SQL. As it is written it is a specific language added to Oracle SQL databases. Does it mean that this language is only available on Oracle DBs? And is not available on postgres, mysql and sqlite solutions?
PL/SQL is indeed an Oracle specific language. However most databases have similar languages - SQL Server has T-SQL, Postgres has PL/pgSQL, MySQL has its own variant (which doesn't seem to have a nifty name), etc.
The syntax of all these languages differ, but the concepts are similar.
Related
I have heard that SQL is mostly the same from program to program, but there are some differences. I am wondering if there are any differences in SQL between Access (2007 if it matters) and MS SQL Server? I wonder because I regularly use Access and want to learn SQL from a book, and I wonder if a book using MS SQL Server will serve my purposes? I am considering "Access 2007 Pure SQL" and "Beginning SQL Joes 2 Pros", the second of which uses MS SQL Server. Thanks for any help!
There's multiple differences, even down to simple things like the string concatenation operator. Access uses &, SQL Server uses +. SQL is like English. There's British English, Canadian English, American English, Australian English, etc... Multiple dialects, mostly but not totally compatible with each other.
That's not to say that things are totally imcompatible - learning SQL on any DBMS is of use, because the core concepts of relational databases remain the same regardless of which DBMS you're on. It's just how you interface with them that's different.
MS Access uses JET SQL while SQL Server uses Transact SQL. For the most part, they are very similar. SQL in general is a programming language designed for managing data in relational database management systems. So all the flavors feature a common subset. But there are differences too. For more info, refer to this article on Convert Microsoft Access (JET SQL) to SQL Server (T-SQL) Cheatsheet. There are numerous other resources on web, but this should give you a quick picture of some differences.
I would say that Access SQL and T-SQL (SQL Server) have more differences than similarities. Any appearance of similarity are due to 1) both being based on the SQL-89 Standard (but both T-SQL and the Standards have moved on greatly, Access not so), 2) the SQL Server team tried but failed to make Access2000 (Jet 4.0) compliant with entry level SQL-92 Standard (the de facto "bare minimum" Standard).
Take for example the UPDATE statement. In its simplest form, i.e. involving a literal or input parameter (scalar) values, the two broadly are the same. However, when updating one table using the values from another table, the latest T-SQL syntax (2008) supports the SQL-92 scalar subquery syntax, the SQL-99 and SQL:2003 Standards' MERGE syntax with useful proprietary extensions, plus its older proprietary UODATE..FROM syntax (which should be avoided nowadays because it allows potentially ambiguous results), all of which can optionally use SQL:2003 common table expressions (useful for simplifying the SQL-92 scalar subquery syntax).
For Access you are compelled to use its proprietary UPDATE..FROM syntax, which is not the same as the T-SQL proprietary UPDATE..FROM syntax but has the same problem of allowing potentially ambiguous results (but this time cannot be avoided!), unless the query involves aggregated values in which case you cannot use SQL at all (!!) and must resort to client side (non-SQL) procedural code (because Access does not support procedural SQL code, another huge difference from T-SQL).
All that I know is that the former is Oracle and the latter is SQL Server. I assume some things might be easier in one versus the other but are there certain things I can do in PL that I can't in T?
Are there fundamental differences that I should be aware of? If so, what are they?
T-SQL and PL/SQL are two completely different programming languages with different syntax, type system, variable declarations, built-in functions and procedures, and programming capabilities.
The only thing they have in common is direct embedding of SQL statements, and storage and execution inside a database.
(In Oracle Forms, PL/SQL is even used for client-side code, though integration with database-stored PL/SQL is (almost) seemless)
The only fundamental difference is that PL/SQL is a procedural programming language with embedded SQL, and T-SQL is a set of procedural extensions for SQL used by MS SQL Server. The syntax differences are major. Here are a couple good articles on converting between the two:
http://www.dba-oracle.com/t_convent_sql_server_tsql_oracle_plsql.htm
http://jopinblog.wordpress.com/2007/04/24/oracle-plsql-equivalents-for-ms-sql-server-t-sql-constructs/
They're not necessarily easier, just different - ANSI-SQL is the standard code that's shared between them - the SELECT, WHERE and other query syntax, and T-SQL or PL/SQL is the control flow and advanced coding that's added on top by the database vendor to let you write stored procedures and string queries together.
It's possible to run multiple queries using just ANSI-SQL statements, but if you want to do any IF statements or handle any errors, you're using more than what's in the ANSI spec, so it's either T-SQL or PL/SQL (or whatever the vendor calls it if you're not using Microsoft or Oracle).
One tid bit I can add is take what you know in one and while using the other forget what you know(except for using set based logic when ever possible).
One example of the differences is cursor's are typically considered a less ideal solution in T-SQL unless there is a really good reason to use them which there is often not. In Oracle the cursor's are much more optimized for example they have bulk abilities, that is the ability to work on a set of data much like a normal SQL statement can. So in Oracle using a cursor isn't an instant failed code review where it might in a TSQL code review.
Overall T-SQL is much easier to learn as there's not much to it as far as languages are concerned. PL/SQL is a richer language, and therefore more complicated. It is not a hard language to pick up if have a good book. Overall I really like PLSQL for it's depth and I really like TSQL for it's simplicity.
PL/SQL and T-SQL are extensions for SQL. PL/SQL is used for Oracle databases and T-SQL is used for Microsoft databases.
Here are more useful informations:
http://techdifferences.com/difference-between-t-sql-and-pl-sql.html
word on the street is that Perl is defined not by a spec but by whatever the current interpreter version happens to accept. Now, let's consider an SQL dialect like TSQL. Is there a published spec of it that would allow making a validator equivalent to the one inside SQL Server? Are there such validators already in existence as open source? And the same question for Oracle.
Ok, so for MySQL I am guessing that validator could be extracted directly from the MySQL codebase. Nevertheless, do they in fact publish the spec itself in case I wanted to make my own validator?
You seem to have an idea of what to do for MySQL. I can't really say much about Oracle apart from that it mostly implements ANSI SQL and the PL/SQL procedural language extensions to SQL can mostly be found here for Oracle 9i.
For SQL Server:
Microsoft Books On Line (BOL) is the official reference spec. There are different pages for different versions of SQL Server, however.
There are a few projects relating to this.
http://www.sqlparser.com/ - This has .NET, Java, COM and VCL versions for Oracle, DB2, Mysql and SQL Server / Sybase (T-SQL). Quite reasonably priced too.
http://www.codeproject.com/Articles/1136/SharpHSQL-An-SQL-engine-written-in-C (c#)
http://antlr.org/ - This looks like a good bet.
I often use this site for formatting of SQL but it also does some validation although it's fairly crude:
http://www.dpriver.com/pp/sqlformat.htm
This is a similar site:
http://www.tsqltidy.com/
I would suggest that writing a validator for SQL even in just one of its variations is a massive undertaking. You could look at the various ISO/IEC standards for ANSI SQL. ANSI SQL-92 is very widely implemented, but there is a SQL:2008 standard as well.
You'd have to pay for the documentation for those standards though and they aren't cheap.
Good luck.
I am working on an application that will need to communicate with many different applications running on different database platforms. I will know the table schema before runtime but I won't know the database platform (MS SQL 200X, Oracle 9i, 10g, etc, MySQL 4.0.1, 5.x, etc, sybase, etc) until runtime.
It's my understanding that each of these systems have a slightly different dialect. Do I need to use nhibernate to handle the differences when connecting to these systems or can I use ADO.NET and pass raw SQL strings (select * from table)?
If you only need to use ANSI SQL statements, which should be implemented by all of the databases then yes, you can just use ADO.NET.
In my experience the main problem with database-agnostic code is the use of surrogate keys, like sequences or autonumber fields, as all databases implement these differently.
If you do need to use features that differ across databases then I don't think that it is reason enough to go to an object relational mapper like NHibernate - only do that if you have other reasons to do so. You can implement your own handling of syntax differences by generating different SQL for different databases easily enough.
SQL should be standardized for all dbs but they don't all use the same syntax so it really depends on what SQL you're calling. For example, SQL Server uses TOP while Oracle uses rownum. Even if they're all DDL, some syntactically differences between DBMSes can be an issue.
If select * from table is all you want, then there shouldn't be a problem, other than performance hits.
I have a SQL Server 2000 database with a lot of stored procedures. I want to migrate to a open source database and well I know I will have to re write the procedures but I would like to do this with as little effort as possible
Neither are a direct port, but of the two -- MySQL's syntax is more similar to SQL Server's than PostgreSQL.
SQL Server 2000 didn't have analytic/ranking/windowing functionality -- neither does MySQL currently. Also, no WITH/CTE support - again, MySQL doesn't support this either. If you were migrating away from SQL Server 2005+, I'd have recommended PostgreSQL 8.4+ for the sake of either of the two things I just mentioned.
MySQL's stored procs are really basic, for instance you cannot raise an exception from within a proc, which makes error handling REALLY PAINFUL. Also, debugging stored procs is a pain, the error messages are unclear, and the language itself is pretty limited.
Postgres is much more mature for this ; if your app has lots of stored procs, this pretty much rules out mysql.
MySQL supports stored procedures, per se; PostgreSQL supports stored functions, which are in practice very similar.
The first query language for PostgreSQL, PL/pgSQL, is similar to Oracle's PL/SQL. PostgreSQL supports SQL:2003 PSM stored procedures as well as many other general purpose programming languages such as Perl (PL/Perl), Python (PL/Python), TCL (PL/Tcl), Java (PL/Java) and C (PL/C).
MySQL follows the SQL:2003 syntax for stored routines, which is also used by IBM's DB2.
—MySQL AB , MySQL 5.1 Reference Manual :: 18 Stored Procedures and Functions
Via the plugin interface MySQL supports external language stored procedures in Java, Perl, XML-RPC with more language plugins in the works.
from link text