A primary key (often) consists out of multiple columns. I'd suggest putting the primary key on BOTH, and to add an autoincrement-field and make that unique. Use the autoincrement-column to make relations to other tables.
Why would you not use WharehouseID-ProductID in a concatenated field as a primary key.
That's a possibility; then again, it introduces a concatenation-action, and we'd be storing redundant information. It'd also affect performance; having a large varchar-based key (as two bigints as Id's or Guids would be concatenated to a varchar) would be not-nice for your indexes.
Or, in the words of my teacher; it would no longer be an atomic value.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
Friends i am going to develop a website which is like you tube.so i want to play an add first then i want to play the video on clicking the video file.so help me in writing the code. i wish to use two databases one for adds and other for videos.so please help me writing code
Please do not post questions asking people to write your code for you. Members of this site come here to help people who make an effort to learn and do their own work. If you do not know how to begin to create your project then find some online study guides, or buy some books.
From the Oracle language reference: The (+) operator can be applied only to a column, not to an arbitrary expression. However, an arbitrary expression can contain one or more columns marked with the (+) operator.
So the second syntax looks valid to me. Does it give you the expected results?
"The ones who care enough to do it right care too much to compromise."
By the way, 50 km is about half a degree. Depending on the amount of rows in your table, it might be wise to filter for longitude between -122.5 and -121.5 and latitude between 36.5 and 37.5 first.
Also a simple transformation with 110 km/degree for latitude, and 110 * cos(latitude) for longitude, and then using simple pythagoras might speed up the query.
To add to Jorgen's answer, I've always wondered why SQL Server doesn't allow us to use alias in WHERE and HAVING clauses. The answer to that lies in the logical order in which the query is processed. The WHERE and HAVING clauses are processed before the SELECT clause and the alias do not exist at that stage.
However, technically it should be possible to introduce another stage earlier in the query processing pipeline where a mapping between expressions and their alias is made and WHERE and HAVING clauses can look up to these mappings and substitute the actual expression in place of the alias.