there is an specify remark for SELECT INTO clause,that I don't know it?is SELECT INTO a DDL or DML?I will appreciate if explain me that specify remark?
thanks
I would say DML as DDL is used to define the database structure, and DML for managing data.
Select into is not different from a insert into, I belive.
Both. It's DDL because it changes the catalog. It's DML because SELECT is DML.
The Wikipedia article on Data manipulation language says (highlighting is mine):
The SQL-data change statements are a subset of the SQL-data statements; this also contains the SELECT query statement, which strictly speaking is part of the DQL, not the DML. In common practice though, this distinction is not made and SELECT is widely considered to be part of DML, so the DML consists of all SQL-data statements, not only the SQL-data change statements. The SELECT ... INTO ... form combines both selection and manipulation, and thus is strictly considered to be DML because it manipulates (i.e. modifies) data.
I Think Basically Select into is a combination query provided by microsoft from Sql server 2008 onwards to backeup data to a table, here we using DDL for creating table and DML for insertion at the definition level of SELECT INTO.
Related
Do CTEs use any space in tempdb or does it use memory exclusively?
I've tagged the question with both mssql 2005 and 2008 as I use both.
I'll try not to copy/paste MSDN
It doesn't matter.
A CTE is independent of query execution: it is only a language construct. Think of it as neat derived table or subquery.
This means that except for recursive CTEs (see later), all CTEs can be coded inline. If you use the CTE code once, it is for readability. If you use the CTE twice or more, then it is defensive: you don't want to make a mistake and have the derived table different each use.
Where a CTE is used twice or more, then that code will be executed twice or more. It won't be executed once and cached in tempdb.
Summary: it may or may not, just like if the code was inline.
Note: a recursve CTE is simply a derived table inside a derived table inside a derived table inside a a derived table inside a der... so same applies.
You can see this in Tony Rogerson's article. The use of tempdb would happen anyway if coded inline. He also notes that using a temp table can be better because of the "macro" expansion I explained above
FYI: the same applies to views. Just macros.
A common table expression can be thought of as a temporary result set
that is defined within the execution scope of a single SELECT, INSERT,
UPDATE, DELETE, or CREATE VIEW statement. When the query plan for a
common table expression query uses a spool operator to save
intermediate query results, the Database Engine creates a work table
in tempdb to support this operation.
source
From MSDN: http://msdn.microsoft.com/en-us/library/ms345368.aspx
A common table expression can be thought of as a temporary result set that is defined within the execution scope of a single SELECT, INSERT, UPDATE, DELETE, or CREATE VIEW statement.
When the query plan for a common table expression query uses a spool operator to save intermediate query results, the Database Engine creates a work table in tempdb to support this operation.
I'm writing an application to move data from Oracle to Sybase and need to perform update / insert operations. In Oracle, I'd use MERGE INTO, but it doesn't seem to be available in Sybase (not in ASE, anyway). I know this can be done with multiple statements, but for a couple of reasons, I'm really trying to get this into a single statement.
Any suggestions?
ASE 15.7 has this feature.
Find the docs here:
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc36272.1570/html/commands/commands84.htm
Sybase and DB2 are very IEC/ISO/ANSI SQL Standrd-compliant. MS a little less so.
Oracle is not very Standard-compliant at all (despite what the glossies say). More important, due to it limitations, the method they use to overcome them is to introduce Extensions to SQL (which are not required for the others DBMS, which do not have the limitations). Nice way of making sure that customers do not migrate away.
So the best advice for you is to learn the SQL Standard way of doing whatever you were doing on the Oracle side. And second (not first) learn about Sybases or DB2s (or whatever) Extensions.
"MERGE" and "UPSERT" do not exist in SQL, they exist in Oracle only. The bottom line is, you have to UPDATE and INSERT in two separate operations.
In SQL, UPDATE and INSERT apply to a single table; you may have quite complex FROM clauses.
For "MERGE", that is simply an:
INSERT target ( column_list ) -- we do have defaults
SELECT ( column_list )
FROM source
WHERE primary_key NOT IN ( SELECT primary_key FROM target )
Update is simply the complement:
UPDATE target SET ( target_column = source_column, ... )
FROM source
WHERE primary_key IN ( SELECT primary_key FROM target )
In the UPDATE it is easy to merge the WHERE conditions and eliminate the Subquery (I am showing it to you for explanation).
As I understand it, Oracle is abyssmal at executing Subqueries (Standard SQL). Which is why they have all these non-Standard "MERGE", etc., the purpose of which is to avoid the Standard Subquery syntax, which every other DBMS performs with ease.
unfortunately, it is impossible to insert and update a table in one statement without using MERGE. which btw does exist in SQL as of SQL:2008, according to this article anyway, and supported by almost all major databases, except Sybase ASE and PostgreSQL.
Merge exists in SAP ASE 15.7 upwards, as mentioned here and here
Replace / Upsert exists in SAP ASE 16.0 and up.
You'll need to update to access them.
Maybe it could work. Tested in ASA9.
insert into my_table (columns) on existing update values (values);
May be you could try to fake it with INSERT INTO and/or UPDATE FROM with some sub-queries but it will not be as convenient as Oracle does.
You wanna do this into code or data warehouse ? because you could also encapsulate all the SQL into a stored procedure if you want to hide the complexity of the queries.
DDLs and DMLs are two strict categories of types of statements used for interacting with a database. I am not sure why this categorization exists.
Is there a fundamental difference in the way an Oracle database would work internally with respect to a DDL and DML statement?
One major (technical) difference between DDL and DML in Oracle is, that DDL is not transactional, i.e. they cannot be rolled back and don't require a commit. As a matter of fact DDL in Oracle does an implicit commit before it's executed.
Other databases (e.g. Postgres, DB2) do not make a difference with regards to transactions between DDL and DML
After all it's just a categorization, similar to the terms "application" and "server" (as in database server). From an operating point of view, OpenOffice and Oracle are both simply "applications", but yet we classify them into different categories.
DDL statements are used to define database structures, objects, and schemas whereas DML statements are used for managing data within schema objects. At the end of the day, Oracle (o r any other data management system) would process each type statement according to security permissions and object availability (i.e. locks on tables / views and isolation levels).
Also, schema definitions are held in internal master tables so your DDL statements actually affect the data stored in those tables and perhaps can be considered "master DML" statements in that sense.
If your question amounts to "is there a reason why it is necessary for DDL and DML to "be implemented differently", the answer is "NO".
However, the definers of the SQL language have opted for making DDL syntactically distinct. As a consequence, adding a column to a table must be done through the appropriate ALTER TABLE command. A side-effect of that command is that a row gets inserted in the catalog table that documents all columns. Stress side-effect.
But there is no fundamental reason why the insertion of a row in the catalog table could not be the trigger itself for the column addition, thus entirely eliminating the need for any "dedicated DDL".
Will it be possible to insert into two tables with same insert command?
No you cannot perform multiple inserts into two tables in one query.
No you can't.
If you want to ensure the atomicity of an operation that requires data to be inserted into 2 tables, you should protect it in a transaction. You either use the SQL statements BEGIN TRAN and COMMIT TRAN, or you use a transaction boundary in whatever language you're using to develop the db access layer. E.g. something like Connection.StartTransaction and Connection.Commit (or Connection.Rollback on an error).
You can call a stored procedure with inserts into two tables.
Maybe in a future release of MySQL you could create a View containing the 2 tables and insert into that.
But with MySQL 5.1.41 you'll get the error:
"Can not modify more than one base table through a join view"
But inserting into 2 tables with 1 query is a weird thing to do, and I don't recommend it.
For more on updatable views check out the MySQL reference.
If a "WITH NOLOCK" query hint is used on a View in SQL Server, does it propagate that hint to the view definition itself, even if NOLOCK is NOT used for the raw tables in the View definition? The reason to need this is that sometimes the support staff wants to do huge time-consuming queries but would rather not force this lock on all queries using the view within the application itself.
Yes, NOLOCK will propagate to the tables used by the view definition (at least in SQL Server 2005).
See Table Hints in MSDN:
In SQL Server 2005, all lock hints are propagated to all the tables and views that are referenced in a view. Also, SQL Server performs the corresponding lock consistency checks.
However,
If a table contains computed columns and the computed columns are computed by expressions or functions accessing columns in other tables, the table hints are not used on those tables. This means the table hints are not propagated. For example, a NOLOCK table hint is specified on a table in the query. This table has computed columns that are computed by a combination of expressions and functions that access columns in another table. The tables referenced by the expressions and functions do not use the NOLOCK table hint when accessed.
If you're using indexed views you might want to read a bit more as there are some special cases there too.
Also see View Resolution for more info.
Just to supplement Rory's excellent answer.
He writes "Yes, NOLOCK will propagate to the tables used by the view definition (at least in SQL Server 2005)."
In fact this will work in SQL 2000 as well.
From BOL:
Because select_statement uses the SELECT statement, it is valid to use and hints as specified in the FROM clause. For more information, see FROM and SELECT.