Performance Tuning of View

Question

Hi All,
I have 2 tables.
Parts and Part_Property
Parts
Part ID Status 
1 Complete
2 Pending
3 Complete
Part Property
Part ID Status
Part Type Part String
1 Complete
Active True
1 Complete
Data_Status Raw
1 Complete
Temp_Verification Valid_Test
1 Complete
Name Screw
2 Complete
Active False
2 Complete
Data_Status Raw
2 Complete
Temp_Verification Valid_Test
2 Complete
Name Hooks
3 Complete
Active True
3 Complete
Data_Status Raw
3 Complete
Temp_Verification Valid_Test
3 Complete
Name Bolt
The above rows are small set of data. Our Previous code with Left Outer Join, has huge Scan Count > 15000 and Logical Reads > 40000. And the users complain that it is very slow always.
 SQL Server Execution Times:
   CPU time = 313 ms,  elapsed time = 318 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.
Is there any way to overcome these performance bottleneck ?

Answer 1

You violated ISO-11179 naming standards. You violated First Normal Form(1NF).
You have committed EAV (Entity-Attribute-Value), a huge design flaw. We never, never, never mix data and meta data in a table. Using "VW_" in the names of VIEW is called "Volkswagen Programming", another noob error
This is a pretty simple and very clean EAV example. In practice you will see one table, descriptively named something like "DATA", all NULL-able columns, no attempt at keys and worse. Much worse. 
CREATE TABLE Attributes_Values 
(attribute_name VARCHAR (10) NOT NULL,
 attribute_value VARCHAR (50) NOT NULL,
 PRIMARY KEY (attribute_name, attribute_value));
INSERT INTO Attributes_Values 
VALUES ('LOCATION', 'Bedroom'),
       ('LOCATION', 'Dining Room'),
       ('LOCATION', 'Bathroom'),
       ('LOCATION', 'courtyard'),
       ('EVENT', 'verbal aggression'),
       ('EVENT', 'peer'),
       ('EVENT', 'bad behavior'),
       ('EVENT', 'other');
CREATE TABLE Entities 
(physical_row_locator INTEGER IDENTITY (1,1) NOT NULL,
 generic_entity_id INTEGER, 
 attribute_name VARCHAR (10) NOT NULL, 
 attribute_value VARCHAR (50) NOT NULL,
  FOREIGN KEY (attribute_name, attribute_value)
   REFERENCES Attributes_Values (attribute_name, attribute_value)
INSERT INTO Entities 
VALUES (1, 'LOCATION', 'bedroom'),
       (1, 'EVENT', 'other'),
       (1, 'EVENT', 'bad behavior'),
       (2, 'LOCATION', 'bedroom'),
       (2, 'EVENT', 'other'),
       (2, 'EVENT', 'verbal aggression'),
       (3, 'LOCATION', 'courtyard'),
       (3, 'EVENT', 'other'),
       (3, 'EVENT', 'peer');
Please notice that there is nothing to prevent me from inserting a row (2, 'AUTHORITY', 'police')  or (42, 'SHOESIZE',  '10') that may or may not make sense.  No two generic_entity_id's are required to have the same structure when you join their
attributes together. There is no restriction on the attribute names or values; every typo is a new attribute or value. 
The poster wanted a simple (Location, Event, COUNT(*) ) report. That is about as basic as you can get. Here is one shot at it. 
WITH Locations (location_name) -- notice aliasing!
AS
(SELECT attribute_value
   FROM Attributes_Values AS AV1
  WHERE attribute_name = 'LOCATION'), 
Events (incident_type) -- notice aliasing!
AS
(SELECT attribute_value
   FROM Attributes_Values AS AV2
  WHERE attribute_name = 'EVENT'),
Incidents (incident_nbr, location_name, incident_type) -- notice aliasing!
AS
(SELECT L1.generic_entity_id, L1.location_name, E1.incident_type
   FROM Locations AS L1,
        Events AS E1
  WHERE L1.generic_entity_id = E1.generic_entity_id
SELECT location_name, incident_type, COUNT(*) AS incident_cnt
  FROM Incidents 
 GROUP BY location_name, incident_type;
This is a general pattern for EAV queries. Each column is extracted from the Attribute-Values table. A query with (n) columns becomes an n-way self-join under the covers. Then each of those working tables will need (n-1) joins to the Entities table. This gives
us something like a table, but it has no data integrity, guarantee of a key, constraints, nor numeric and temporal data types. 
The use of CTEs is simply to make the query easier to read. It does not help performance. You also have to give particular names to the generic data as you extract it.  How do you get everyone to agree on those names? 
Did you want to add a 'FINE" attribute to the table? Well, the values can hold only character data. so you now have the overhead of CAST() calls. In fact, since you cannot predict what will go into a column, you have to use the most general data type you can
find to cast to anything else -- NVARCHAR (MAX).  But you will probably use a  VARCHAR(<big number here>) instead. 
I worked for a software company that used an EAV model for a package to compute insurance salesman's commission based on an elaborate tiered scheme. They got paid based on the performance of their personal sales, their team's sales, their district sales and
finally the company as a whole.  This is a fairly common way to compute commissions.  
The reason given for the EAV model was that the commission algorithm could be easily changed by end users on the fly. The bad news was that it was changed by the end users on fly. Orphan rows could not be removed for fear of breaking something even if you could
figure out the chains of GUIDs used to link things together.  Servers fill with junk data and locked up the system in a few months. 
The bigger problem is that EAV has no data integrity. Consider the constraints you need to add  to the simple Attributes_Values table to make it almost work:
INSERT INTO Attributes_Values 
VALUES ('LOCATION', 'bedroom'),
       ('LOCATION', 'dining room'),
       ('LOCATION', 'bathroom'),
       ('LOCATION', 'courtyard'),
       ('EVENT', 'verbal aggression'),
       ('EVENT', 'peer'),
       ('EVENT', 'bad behavior'),
       ('EVENT', 'other');
CREATE TABLE Attributes_Values 
(attribute_name VARCHAR (10) NOT NULL,
 attribute_value VARCHAR (50) NOT NULL,
 PRIMARY KEY (attribute_name, attribute_value),
CONSTRAINT Valid_Attribute_Names
CHECK (attribute_name IN ('LOCATION', 'EVENT')),
 CONSTRAINT Generic_DRI
CHECK (CASE WHEN attribute_name = 'LOCATION'
             AND attribute_value 
              IN ('bedroom', 'dining room', 'bathroom', 'courtyard')
            THEN 'T'
            WHEN attribute_name = 'EVENT' 
             AND attribute_value 
              IN ('verbal aggression', 'peer', 'bad behavior', 'other')
            THEN 'T' ELSE 'F' END = 'T')
Now add a FINE attribute and constraint it to being non-negative money amounts. Now add a constraint that the amount of the fine cannot be over $5.00 if the event was 'verbal aggression' in a bedroom. 
Try to write a single DEFAULT clause for all the entities crammed into one column. Impossible, unless they all happen to use NULL. 
This is the same thing in a proper schema would start with a sane schema design. There should be separate referenced tables or CHECK() constraints for Locations and Events, since they are attributes of something. 
CREATE TABLE Incident_Reports
(incident_report_nbr CHAR(12) NOT NULL PRIMARY KEY, 
 location_code VARCHAR(15) NOT NULL
   REFERENCES Locations (location_code)
   ON DELETE CASCADE
   ON UPDATE CASCADE,
 incident_type VARCHAR(20) NOT NULL
   REFERENCES Incident_Types (incident_type)
   ON UPDATE CASCADE,
 etc); 
Entities, attributes and values are where they belong, so the query is now trivial: 
SELECT location_code, incident_type, COUNT(*)
  FROM Incident_Reports
 GROUP BY location_code, incident_type;
Then I could get fancier report with a simple change to the GROUP BY clause:
SELECT location_code, incident_type, COUNT(*)
  FROM Incident_Reports
 GROUP BY ROLLUP (location_code, incident_type);
The EAV version is left as an exercise for the reader. 
There is such a thing as "too" generic.  "To be is to be something in particular; to be nothing in particular or everything in general is to be nothing at all." --Law of Identity, Parmenides the Eleatic (circa BCE 490) 
References
For those who are interested, there are couple of links to articles on EAV I found on the net: 
Generic Design of Web-Based Clinical Databases 
http://www.jmir.org/2003/4/e27/ 
The Attributes_Values/CR Model of Data Representation 
http://ycmi.med.yale.edu/nadkarni/eav_CR_contents.htm 
An Introduction to Entity-Attribute-Value Design for Generic Clinical Study Data Management Systems 
http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm 
Data Extraction and Ad Hoc Query of an Entity-Attribute-Value Database 
http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pubmed&pubme... 
Exploring Performance Issues for a Clinical Database Organized Using an Entity-Attribute-Value Representation 
http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pubmed&pubme... 
A really good horror story about this kind of disaster is at:
http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL