Left join and where clause with not equal ( ) returns too many rows

Question

Say I have something like this
Table A
=========
Id
OrderNum
Date
StoreName
AddressKey
Table B
========
Id
StreetNumber
City
State
select a.* from [Table A] a
left join [Table B] b on a.AddressKey = b.Id
where a.StoreName <> 'Burger place'
The trouble is that the above query still returns rows that have StoreName = 'Burger place'
One way Ive handled this is to use a table expression, select everything into that, then select from the CTE and apply the filter there.  How could you handle it in the same query however?

Answer 1

Hi Joe,
Thanks for your notes.
INT SURROGATE PRIMARY KEY provides a small footprint JOIN ON column. Hence performance gain and simple JOIN programming.  In the Addresses table, address_id is 4 bytes as opposed to 15 bytes san. Similarly for the Orders table.
INT SURROGATE PRIMARY KEY is a meaningless number which can be duplicated at will in other tables as FOREIGN KEY.  Having a meaningful PRIMARY KEY violates the RDBMS basics about avoiding data duplication.  If I make CelebrityName (Frank Sinatra)
a PRIMARY KEY, I have to duplicate "Frank Sinatra" as an FK wherever it needed as opposed to duplicating SURROGATE PRIMARY KEY CelebrityID (79) a meaningless number.
This is how we design in SQL Server world.
QUOTE from Wiki: "
Advantages[edit]
Immutability[edit]
Surrogate keys do not change while the row exists. This has the following advantages:
Applications cannot lose their reference to a row in the database (since the identifier never changes).
The primary or natural key data can always be modified, even with databases that do not support cascading updates across related
foreign keys.
Requirement changes[edit]
Attributes that uniquely identify an entity might change, which might invalidate the suitability of natural keys. Consider the following example:
An employee's network user name is chosen as a natural key. Upon merging with another company, new employees must be inserted. Some of the new network user names create conflicts because their user names were generated independently (when the companies
were separate).
In these cases, generally a new attribute must be added to the natural key (for example, an
original_company column). With a surrogate key, only the table that defines the surrogate key must be changed. With natural keys, all tables (and possibly other, related software) that use the natural key will have to change.
Some problem domains do not clearly identify a suitable natural key. Surrogate key avoids choosing a natural key that might be incorrect.
Performance[edit]
Surrogate keys tend to be a compact data type, such as a four-byte integer. This allows the database to query the single key column faster than it could multiple columns. Furthermore a non-redundant distribution of keys causes the resulting
b-tree index to be completely balanced. Surrogate keys are also less expensive to join (fewer columns to compare) than
compound keys.
Compatibility[edit]
While using several database application development systems, drivers, and
object-relational mapping systems, such as
Ruby on Rails or
Hibernate, it is much easier to use an integer or GUID surrogate keys for every table instead of natural keys in order to support database-system-agnostic operations and object-to-row mapping.
Uniformity[edit]
When every table has a uniform surrogate key, some tasks can be easily automated by writing the code in a table-independent way.
Validation[edit]
It is possible to design key-values that follow a well-known pattern or structure which can be automatically verified. For instance, the keys that are intended to be used in some column of some table might be designed to "look differently from"
those that are intended to be used in another column or table, thereby simplifying the detection of application errors in which the keys have been misplaced. However, this characteristic of the surrogate keys should never be used to drive any of the logic
of the applications themselves, as this would violate the principles of
Database normalization"
LINK: http://en.wikipedia.org/wiki/Surrogate_key
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014