1. SQL Server 2005 Implementation and Maintenance Chapter 3: Tables and Views

2. Tables  Tables hold all of the data  Tables are made of two smaller objects  Fields All data of a specific type  Records A group of related fields © Wiley Inc. 2006. All Rights Reserved.

3. Datatypes  Datatypes restrict the types of data that a field can hold  Example: you can’t store letters in a field using the int datatype  You can store numbers in a char datatype field You cannot perform math on them though, they are just characters  There are several to choose from © Wiley Inc. 2006. All Rights Reserved.

4. Datatypes, Cont.  Bit  Int  Bigint  Smallint  Tinyint  Decimal  Numeric  money © Wiley Inc. 2006. All Rights Reserved.  Smallmoney  Float  Real  Datetime  Smalldatetime  Timestamp  Uniqueidentifier  Char  Varchar  Varchar(max)  Nchar  Nvarchar  Nvarchar(max)  Binary  Varbinary  Varbinary(max)

5. Datatypes, Cont.  Xml  Identity  Sql_variant  Table  Cursor  Computed columns © Wiley Inc. 2006. All Rights Reserved.

6. Check Constraints  A T-SQL statement that Column-level – apply to column (cannot refer to other columns) Table-level – apply to table (cannot refer other tables)  Column-level restricts data that can be inserted in the field, even if it is the correct datatype Example: XZ is char data, but it is not a valid state abbreviation Check (GPA = 0) © Wiley Inc. 2006. All Rights Reserved.

7. Add a check constraint CREATE TABLE dbo.Vendors (VendorID int PRIMARY KEY, VendorName nvarchar (50), CreditRating tinyint) GO ALTER TABLE dbo.Vendors ADD CONSTRAINT CK_Vendor_CreditRating CHECK (CreditRating >= 1 AND CreditRating <= 5)

8. Add a table level constraint CREATE TABLE CheckTbl (col1 int, col2 int); GO CREATE FUNCTION CheckFnctn() RETURNS int AS BEGIN DECLARE @retval int SELECT @retval = COUNT(*) FROM CheckTbl RETURN @retval END; GO ALTER TABLE CheckTbl ADD CONSTRAINT chkRowCount CHECK (dbo.CheckFnctn() >= 1 ); GO

9. Default Constraints  Used to fill in blank fields on an INSERT  Some considerations Can’t be used on columns with the timestamp datatype Can’t be used on IDENTITY columns. Can’t be used on columns with the ROWGUIDCOL property set © Wiley Inc. 2006. All Rights Reserved.

10. Unique Constraints  These ensure that no duplicate values can be added to a field A field that holds social security number data may be a good candidate © Wiley Inc. 2006. All Rights Reserved.

11. Partitioning Tables  Very useful for DSS, book’s examples are incorrect and incomplete --- SKIP © Wiley Inc. 2006. All Rights Reserved.

12. Views  Described as a virtual table, or a stored SELECT query  Views represent the data stored in a table  They do not hold data themselves  Useful when you do not want to show all available data © Wiley Inc. 2006. All Rights Reserved.

13. Modifying Data With Views  Views can be used to modify data  If you use a view to modify data, the modification can affect only one base table at a time.  You can't modify data in a view that uses aggregate functions.  If you try to insert a record into a view that doesn't show all fields, and those fields do not accept NULL values, your insert will fail. © Wiley Inc. 2006. All Rights Reserved.

14. Indexed Views  Each time a view is queried it must be materialized SQL Server must gather the data from the table to show the user  This can be a costly process for complex views  Indexing a view creates a pre-materialized view in the database © Wiley Inc. 2006. All Rights Reserved.

15. Indexed View Considerations  The ANSI_NULLS and QUOTED_IDENTIFIER options must be turned on when the view is created. To do this, use the sp_dboption stored procedure:  The ANSI_NULLS option must have been turned on during the creation of all the tables that are referenced by the view.  The view can't reference other views, only tables.  Any user-defined function's data access property must be NO SQL and external access property must be NO.  All the tables referenced by the view must be in the same database as the view and must have the same owner as the view © Wiley Inc. 2006. All Rights Reserved.

16. Indexed View Considerations, Cont.  The view must be created with the SCHEMABINDING option. This option prohibits the schema of the base tables from being changed (adding or dropping a column, for instance).  Any user-defined functions referenced in the view must have been created with the SCHEMABINDING option as well.  All objects in the view must be referenced by their two-part names: owner.object. No one-, three-, or four-part names are allowed.  Any functions referenced in an indexed view must be deterministic, which means they return the same value each time they're invoked with the same arguments © Wiley Inc. 2006. All Rights Reserved.

17. Indexed View Select Statement  Column names must be explicitly stated in the SELECT statement; you can't use * or tablename.* to access columns.  You may not reference a column twice in the SELECT statement unless all or all but one reference to the column is made in a complex expression.  You may not use a derived table that comes from using a SELECT statement encased in parentheses in the FROM clause of a SELECT statement.  You can't use ROWSET, UNION, TOP, ORDER BY, DISTINCT, COUNT(*), COMPUTE, or COMPUTE BY. © Wiley Inc. 2006. All Rights Reserved.

18. Indexed View Select Statement, Cont.  Subqueries and outer or self JOINs can't be used.  The AVG, MAX, MIN, STDEV, STDEVP, VAR, and VARP aggregate functions aren't allowed in the SELECT statement.  A SUM() that references a nullable expression isn't allowed.  CONTAINS and FREETEXT aren't allowed in the SELECT statement.  If you use GROUP BY, you can't use HAVING, ROLLUP, or CUBE, and you must use COUNT_BIG() in the select list. © Wiley Inc. 2006. All Rights Reserved.