Book Image

Data Analysis Using SQL and Excel - Second Edition

By : Gordon S. S. Linoff
Book Image

Data Analysis Using SQL and Excel - Second Edition

By: Gordon S. S. Linoff

Overview of this book

Data Analysis Using SQL and Excel, 2nd Edition shows you how to leverage the two most popular tools for data query and analysis—SQL and Excel—to perform sophisticated data analysis without the need for complex and expensive data mining tools. Written by a leading expert on business data mining, this book shows you how to extract useful business information from relational databases. You'll learn the fundamental techniques before moving into the "where" and "why" of each analysis, and then learn how to design and perform these analyses using SQL and Excel. Examples include SQL and Excel code, and the appendix shows how non-standard constructs are implemented in other major databases, including Oracle and IBM DB2/UDB. The companion website includes datasets and Excel spreadsheets, and the book provides hints, warnings, and technical asides to help you every step of the way. Data Analysis Using SQL and Excel, 2nd Edition shows you how to perform a wide range of sophisticated analyses using these simple tools, sparing you the significant expense of proprietary data mining tools like SAS.
Table of Contents (18 chapters)
Free Chapter
1
Foreword
17
EULA

When OR Is a Bad Thing

OR is a very powerful construct in databases. Unfortunately, it is one that optimizers often do not handle well, at least with respect to indexes.

Simple WHERE clauses with conditions on only a single column generally do not pose a problem. SQL optimizers are smart enough to use an index on Orders(State)for a query such as:

SELECT o.*
FROM Orders o
WHERE State = 'MA' OR State = 'NY'

Note that this would be better written with IN. The two constructs are usually identical with respect to optimization.

Sometimes UNION ALL Is Better Than OR

Consider an index on Orders(State, City) and a query to fetch orders from Boston and Miami:

SELECT o.*
FROM Orders o
WHERE (o.State = 'MA' AND o.City = 'BOSTON') OR
      (o.State = 'FL' AND o.City = 'MIAMI')

SQL optimizers may not recognize the opportunity to use the index because of the OR. Even if the optimizer is smart enough in this case, it may miss the opportunity...