Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
Microsoft SQL Server Programming
- An Outline for Development
- Database Services
- Database Objects: Databases
- Database Objects: Tables
- Database Objects: Table Relationships
- Database Objects: Keys
- Database Objects: Constraints
- Database Objects: Data Types
- Database Objects: Views
- Database Objects: Stored Procedures
- Database Objects: Indexes
- Database Objects: User Defined Functions
- Database Objects: Triggers
- Database Design: Requirements, Entities, and Attributes
- Business Process Model Notation (BPMN) and the Data Professional
- Business Questions for Database Design, Part One
- Business Questions for Database Design, Part Two
- Database Design: Finalizing Requirements and Defining Relationships
- Database Design: Creating an Entity Relationship Diagram
- Database Design: The Logical ERD
- Database Design: Adjusting The Model
- Database Design: Normalizing the Model
- Creating The Physical Model
- Database Design: Changing Attributes to Columns
- Database Design: Creating The Physical Database
- Database Design Example: Curriculum Vitae
- The SQL Server Sample Databases
- The SQL Server Sample Databases: pubs
- The SQL Server Sample Databases: NorthWind
- The SQL Server Sample Databases: AdventureWorks
- The SQL Server Sample Databases: Adventureworks Derivatives
- UniversalDB: The Demo and Testing Database, Part 1
- UniversalDB: The Demo and Testing Database, Part 2
- UniversalDB: The Demo and Testing Database, Part 3
- UniversalDB: The Demo and Testing Database, Part 4
- Getting Started with Transact-SQL
- Transact-SQL: Data Definition Language (DDL) Basics
- Transact-SQL: Limiting Results
- Transact-SQL: More Operators
- Transact-SQL: Ordering and Aggregating Data
- Transact-SQL: Subqueries
- Transact-SQL: Joins
- Transact-SQL: Complex Joins - Building a View with Multiple JOINs
- Transact-SQL: Inserts, Updates, and Deletes
- An Introduction to the CLR in SQL Server 2005
- Design Elements Part 1: Programming Flow Overview, Code Format and Commenting your Code
- Design Elements Part 2: Controlling SQL's Scope
- Design Elements Part 3: Error Handling
- Design Elements Part 4: Variables
- Design Elements Part 5: Where Does The Code Live?
- Design Elements Part 6: Math Operators and Functions
- Design Elements Part 7: Statistical Functions
- Design Elements Part 8: Summarization Statistical Algorithms
- Design Elements Part 9:Representing Data with Statistical Algorithms
- Design Elements Part 10: Interpreting the Data—Regression
- Design Elements Part 11: String Manipulation
- Design Elements Part 12: Loops
- Design Elements Part 13: Recursion
- Design Elements Part 14: Arrays
- Design Elements Part 15: Event-Driven Programming Vs. Scheduled Processes
- Design Elements Part 16: Event-Driven Programming
- Design Elements Part 17: Program Flow
- Forming Queries Part 1: Design
- Forming Queries Part 2: Query Basics
- Forming Queries Part 3: Query Optimization
- Forming Queries Part 4: SET Options
- Forming Queries Part 5: Table Optimization Hints
- Using SQL Server Templates
- Transact-SQL Unit Testing
- Index Tuning Wizard
- Unicode and SQL Server
- SQL Server Development Tools
- The SQL Server Transact-SQL Debugger
- The Transact-SQL Debugger, Part 2
- Basic Troubleshooting for Transact-SQL Code
- An Introduction to Spatial Data in SQL Server 2008
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Forming Queries Part 2: Query Basics
Last updated Mar 28, 2003.
In part one of this series, I discussed the holistic view of creating Transact-SQL statements. I mentioned the "CRUD" matrix which stands for Create, Read, Update and Delete operations. In today's article, we'll continue that process with the syntax that forms the basis for all queries.
I'll cover the statements in the "CRUD" order. Most tutorials begin with the SELECT statement, but I think we need to put data into the database before we can select it. As a result, we'll start with the statements that create data. I make the assumption that you've already designed your database, tables, and other objects. For this article, I'll use the pubs database.
The "Create" part of the CRUD matrix corresponds to the T-SQL INSERT statement. The INSERT statement has the following syntax:
INSERT INTO table (columns) VALUES (value, or DEFAULT) <<table hints>>
The INTO is actually optional, but I'm old school, so I still use it. What follows is the table name, and then the columns you want to put data into. You don't have to have the columns listed, if you're inserting data into all of them or if you use another syntax, like this:
INSERT INTO table DEFAULT VALUES GO
The caveat for this kind of insert is that each column must have a default value assigned.
When you're inserting data into a column, the data type must match what the column calls for. You must single-quote character strings, and you don't quote numeric values.
Here's an example of putting a new author in the pubs database:
INSERT INTO pubs.dbo.authors ( au_id , au_lname , au_fname , contract) VALUES ( '123-45-6789' , 'Woody' , 'Buck' , 1) GO
Note that I'm following the syntax I mention throughout all my articles with the commas at the front of the field lists. SQL Server ignores the whitespace anyway; I do this just to make sure I don't miss anything.
One other note it's usually a good idea to have the table name prefaced as I have here. You'll actually save a microsecond or two when the statement is compiled if you do that. You can also bracket the field names with , which is required if the field name has spaces in it. (You didn't do that when you created your database, did you?)
Notice also that I've only filled out four fields. The others either have defaults, or aren't required to have a value; they allow NULLs.
There are a couple of things to note about the INSERT statement. If you're inserting data into a table that has a column with IDENTITY set, then the table will automatically create a new value when you run an INSERT statement assuming that you don't try to put one there explicitly. If you do want to explicitly use a value, you'll need to use the IDENTITY INSERT predicate first. You can find out more about that in Books Online.
You can also insert data into a table based on the result of a SELECT statement. Let's assume that you've got a duplicate of the authors table, called authors2:
INSERT INTO authors2 SELECT * FROM authors GO
The reason this statement works is that the column names are in the same order, and the data types all match.
You can also use the results from a stored procedure this way. We'll see that process a little later on.
Now that we've got the "C" in "CRUD", let's change the data around. You can use the UPDATE statement to change data once it's in the table. Here's the syntax:
UPDATE tablename SET columname='Value' WHERE columnname = 'ColumnValue' GO
You can update as many columns as you want, and the WHERE is optional. If you don't specify the WHERE clause, you'll update ALL the columns in the column list to have the same value.
Let's use the UPDATE syntax to give Buck a home and a phone number:
UPDATE pubs.dbo.authors SET phone='123 123-1234' , address='1313 Mockingbird Lane' , city='Tampa' , state='FL' , zip='12345' WHERE au_fname = 'Buck' GO
You have the full WHERE joining syntax available in this command and you can also use sub-selects as a condition for the update.
Next, we can get rid of data: the "D" in "CRUD". There are a couple of things you need to learn about this command even before you learn the syntax. For one thing, a delete is a delete. You can't get it back. Make sure you really want to do that when you call the statement.
Second, make sure you're looking for DELETE. If you want to get rid of an object completely (such as a table or view), what you want is the DROP command. DELETE removes rows, always.
Finally, DELETE uses the transaction log. This means that if you have to delete an entire table, it's often more optimal to use the TRUNCATE command, like this:
TRUNCATE TABLE test1 GO
To delete rows based on a condition, however, you do want the DELETE command. Here's the syntax:
DELETE FROM tablename WHERE condition
The FROM is optional. Again, the condition has the full power of any of the selection logic in the other statements.
Let's get rid of Buck's entry:
DELETE FROM authors WHERE au_fname = 'Buck' AND au_lname = 'Woody' GO
Now that we've created, updated and deleted data, we can use the SELECT command to see the data. This is the most commonly used command in T-SQL, and I've covered it before (Getting Started with Transact-SQL). The basic syntax looks like this:
SELECT fields FROM tables WHERE conditions ORDER BY sort Only the SELECT is required here's an example: SELECT 'Buck' GO
I won't cover the basics again here, but let's take a look at a couple of simple tricks you can do with the SELECT command. You've seen one already; you can select a constant with a single command. You can do the same thing with a variable.
To format the results of a select command, you can use either a comma or a plus-sign (+). A common request is to format results on one line at a time, with all the trailing spaces removed, as with a standard mailing address. Here's a query that does just that:
SELECT au_fname + ' ' + au_lname + CHAR(13) + address + CHAR(13) + city + ' ' + state + ' ' + zip + CHAR(13)+ CHAR(13) FROM authors GO
Here's how that happens. The plus-signs concatenate the fields rather than use standard spacing on them that you see with a comma. Because of that, you have to add spaces, which you can do with the + ' ' + as I've got here, or you could use + SPACE(1) + instead.
At the end of each "row," I include the CHAR(13) function for a carriage-return line-feed. Notice that I end each row with a plus-sign rather than begin the next one with a comma; that's for the formatting again. In essence, this is one long string. At the end I throw in a couple of returns for more spacing.
Now that you've got the basic syntax down for the CRUD operations, join me next time for some tips to make those queries faster.
More online content for the SELECT statement is available here. Judith S. Bowman, Marcy Darnovsky, Sandra L. Emerson do a great job in their article, "Practical SQL: Selecting Data from the Database."
InformIT Tutorials and Sample Chapters
You can find a good "Beginning SQL" book on Safari. One of the best is Sams Teach Yourself SQL in 24 Hours, Second Edition by Ronald R. Plew and Ryan K. Stephens.