Structured Query Language (SQL) - Cultural View of Technology
Structured Query Language (SQL) - Cultural View of Technology Structured Query Language (SQL) - Cultural View of Technology
SQL Access Group 88 SQL Access Group The SQL Access Group (SAG) was a group of software companies that was formed in 1989 to define and promote standards for database portability and interoperability. Initial members were Oracle Corporation, Informix, Ingres, DEC, Tandem, Sun and HP. The SAG started the development of the SQL Call Level Interface which later was published as an X/Open specification. In 1992, Microsoft released version 1.0 of ODBC which was based on the X/Open SQL CLI specification. The SQL Access Group transferred its activities and assets to X/Open in the fourth quarter of 1994. External links • Introduction to SAG CLI by the SAG Chairman on Dr. Dobbs [1] • Data Management: SQL Call Level Interface (CLI) ISBN 1-85912-081-4 Apr 1995 [1] References [1] http://www.ddj.com/database/184410032 SQL CLR SQL CLR or SQLCLR (SQL Common Language Runtime) is technology for hosting of the Microsoft .NET common language runtime engine within SQL Server. The SQLCLR allows managed code to be hosted by, and run in, the Microsoft SQL Server environment. This technology, introduced in Microsoft SQL Server 2005, allow users for example to create the following types of managed code objects in SQL Server in .NET languages such as C# or VB.NET. • Stored procedures (SPs) which are analogous to procedures or void functions in procedural languages like VB or C, • triggers which are stored procedures that fire in response to Data Manipulation Language (DML) or Data Definition Language (DDL) events, • User-defined functions (UDFs) which are analogous to functions in procedural languages, • User-defined aggregates (UDAs) which allow developers to create custom aggregates that act on sets of data instead of one row at a time, • User-defined types (UDTs) that allow users to create simple or complex data types which can be serialized and deserialized within the database. The SQL CLR relies on the creation, deployment, and registration of .NET assemblies, which are physically stored in managed code dynamic load libraries (DLLs). These assemblies may contain .NET namespaces, classes, functions and properties.
SQL CLR 89 External links • MSDN: Using CLR Integration in SQL Server 2005 [1] • MSDN Forum on .NET Framework in SQL Server [2] • SqlClr.net Independent site [3] • SQL CLR Team Blog (No posts since 2006, might be dead) [4] References [1] http://msdn2.microsoft.com/en-us/library/ms345136.aspx [2] http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=86&SiteID=1 [3] http://www.sqlclr.net/ [4] http://blogs.msdn.com/sqlclr/ SQL Problems Requiring Cursors A cursor is a construct available in most implementations of SQL that allows the programmer to handle data in a row-by-row manner. The trouble with cursor processing is that the row-by-row nature cannot easily be made to occur in parallel by database optimizers. This results in a failure of the cursor processing to take full advantage of the processing power available on most database platforms. To overcome this problem, cursor logic can often be converted into set-based SQL queries. Set-based SQL uses the syntax "SELECT...FROM..." with various clauses to perform the data manipulation work. Database optimizers have little trouble dividing such queries into parallel threads, thus fully utilizing the database hardware. The resulting performance gain can be literal orders of magnitude: hours become minutes, and minutes become seconds. Despite the tremendous performce gains from set-based SQL, it can be challenging to find the SQL that replaces fairly straigh-forward cursors. This article discusses examples of such conversions. Constraints In this article, the following constraints apply: • The term "cursor" includes all cursor-like behavior. For example, using a loop in a shell script that loops across SQL queries or the output of SQL queries is cursor-like behavior and does not achieve the goal of true set-based processing within the database. • All set-based SQL must be ANSI SQL. A number of vendors provide some extremely powerful proprietary extensions. The goal is to avoid such extensions in favor of ANSI SQL. • The solution must be generalizable. In one or more examples below, specific values may be used for demonstration purposes, but any solution must scale to any number feasible within the power of the database software and machine resources.
- Page 41 and 42: Database Console Commands (Transact
- Page 43 and 44: Database Console Commands (Transact
- Page 45 and 46: Database Console Commands (Transact
- Page 47 and 48: DbForge Studio for MySQL 43 • Dat
- Page 49 and 50: Declarative Referential Integrity 4
- Page 51 and 52: Devgems Data Modeler 47 External li
- Page 53 and 54: Embedded SQL 49 External links •
- Page 55 and 56: EnterpriseDB 51 EnterpriseDB also o
- Page 57 and 58: Epictetus Database Client 53 Extern
- Page 59 and 60: Foreign key 55 SET NULL The foreign
- Page 61 and 62: FSQL 57 Comparator for Possibility
- Page 63 and 64: Hint (SQL) 59 Hint (SQL) In various
- Page 65 and 66: HSQLDB 61 Transaction support HSQLD
- Page 67 and 68: MaxDB 63 MaxDB Stable release 7.6.0
- Page 69 and 70: Meta-SQL 65 Meta-SQL 'Meta-SQL' Use
- Page 71 and 72: MySQL Workbench 67 MySQL Migration
- Page 73 and 74: MySQL Workbench 69 [14] MySQL Workb
- Page 75 and 76: Navicat 71 Free version Navicat Lit
- Page 77 and 78: PL/pgSQL 73 PL/pgSQL PL/pgSQL (Proc
- Page 79 and 80: PL/SQL 75 User-defined exceptions a
- Page 81 and 82: PL/SQL 77 A selection of other data
- Page 83 and 84: PL/SQL 79 Array handling PL/SQL ref
- Page 85 and 86: PL/SQL 81 Similar languages PL/SQL
- Page 87 and 88: Query optimizer 83 Join ordering Th
- Page 89 and 90: Query plan 85 Query plan A query pl
- Page 91: Rollback (data management) 87 Rollb
- Page 95 and 96: SQL Problems Requiring Cursors 91 S
- Page 97 and 98: SQL injection 93 Incorrect type han
- Page 99 and 100: SQL injection 95 mysql_query($query
- Page 101 and 102: SQL/CLI 97 SQL/CLI The SQL/CLI, or
- Page 103 and 104: SQL/Schemata 99 SQL/Schemata The SQ
- Page 105 and 106: SQLPro SQL Client 101 SQLPro SQL Cl
- Page 107 and 108: Scriptella 103 Scriptella Stable re
- Page 109 and 110: SQL/JRT 105 SQL/JRT The SQL/JRT, or
- Page 111 and 112: SQuirreL SQL Client 107 History The
- Page 113 and 114: Table (database) 109 An equally val
- Page 115 and 116: Truviso 111 Truviso Industry Softwa
- Page 117 and 118: User-defined function 113 User-defi
- Page 119 and 120: User-defined function 115 SAS_Stude
- Page 121 and 122: View (database) 117 View (database)
- Page 123 and 124: View (database) 119 for processing.
- Page 125 and 126: Windows Internal Database 121 Exter
- Page 127 and 128: XLeratorDB 123 Analytic functions S
- Page 129 and 130: XLeratorDB 125 [27] See general Bus
- Page 131 and 132: Article Sources and Contributors 12
- Page 133 and 134: Image Sources, Licenses and Contrib
<strong>SQL</strong> CLR 89<br />
External links<br />
• MSDN: Using CLR Integration in <strong>SQL</strong> Server 2005 [1]<br />
• MSDN Forum on .NET Framework in <strong>SQL</strong> Server [2]<br />
• SqlClr.net Independent site [3]<br />
• <strong>SQL</strong> CLR Team Blog (No posts since 2006, might be dead) [4]<br />
References<br />
[1] http://msdn2.micros<strong>of</strong>t.com/en-us/library/ms345136.aspx<br />
[2] http://forums.micros<strong>of</strong>t.com/MSDN/ShowForum.aspx?ForumID=86&SiteID=1<br />
[3] http://www.sqlclr.net/<br />
[4] http://blogs.msdn.com/sqlclr/<br />
<strong>SQL</strong> Problems Requiring Cursors<br />
A cursor is a construct available in most implementations <strong>of</strong> <strong>SQL</strong> that allows the programmer to handle data in a<br />
row-by-row manner.<br />
The trouble with cursor processing is that the row-by-row nature cannot easily be made to occur in parallel by<br />
database optimizers. This results in a failure <strong>of</strong> the cursor processing to take full advantage <strong>of</strong> the processing power<br />
available on most database platforms.<br />
To overcome this problem, cursor logic can <strong>of</strong>ten be converted into set-based <strong>SQL</strong> queries. Set-based <strong>SQL</strong> uses the<br />
syntax "SELECT...FROM..." with various clauses to perform the data manipulation work. Database optimizers have<br />
little trouble dividing such queries into parallel threads, thus fully utilizing the database hardware.<br />
The resulting performance gain can be literal orders <strong>of</strong> magnitude: hours become minutes, and minutes become<br />
seconds.<br />
Despite the tremendous performce gains from set-based <strong>SQL</strong>, it can be challenging to find the <strong>SQL</strong> that replaces<br />
fairly straigh-forward cursors.<br />
This article discusses examples <strong>of</strong> such conversions.<br />
Constraints<br />
In this article, the following constraints apply:<br />
• The term "cursor" includes all cursor-like behavior. For example, using a loop in a shell script that loops<br />
across <strong>SQL</strong> queries or the output <strong>of</strong> <strong>SQL</strong> queries is cursor-like behavior and does not achieve the goal <strong>of</strong> true<br />
set-based processing within the database.<br />
• All set-based <strong>SQL</strong> must be ANSI <strong>SQL</strong>. A number <strong>of</strong> vendors provide some extremely powerful proprietary<br />
extensions. The goal is to avoid such extensions in favor <strong>of</strong> ANSI <strong>SQL</strong>.<br />
• The solution must be generalizable. In one or more examples below, specific values may be used for<br />
demonstration purposes, but any solution must scale to any number feasible within the power <strong>of</strong> the database<br />
s<strong>of</strong>tware and machine resources.
Change language