A simple DB containing two tables could be:CREATE TABLE Stock ( StockID INT StockDesc VARCHAR SupplierID INT   PRIMARY KEY (StockID) FOREIGN KEY (SupplierID) REFERENCES Supplier(SupplierID))CREATE TABLE Supplier ( SupplierID INT SupplierName VARCHAR PRIMARY  KEY (SupplierID) )(Assume each stockID has only one supplier)A typical SQL query would be:SELECT StockID, StockDesc FROM Stock, Supplier WHERE Stock.SupplierID  = Supplier.SupplierID AND SupplierName = Smiths;My fundamental understanding of Database design alerts me to the fact that I've already established that there is a relationship between STOCK and SUPPLIER tables via the DDL. Why does SQL need to restipulate that fact again in the first WHERE clause?  
Why create Foreign Key References in DDL if using Where clause in SQL?
database design
Note: Assuming that this question is about foreign key constraints rather than the WHERE clause, as WHERE seems to be irrelevant to the question.  I'm assuming you intended JOIN instead.Foreign key references are constraints on modifying operations such as INSERT, UPDATE, and DELETE.     When a constraint exists, it prevents those operations from making changes which might result in a data structure which violates that constraint;  constraints serve the purpose of helping to enforce the integrity/validity of the data in a database by preventing invalid modifications. Constraints are not so relevant to SELECT operations because SELECT is non-modifying, so there's nothing really to protect against. The purpose of a SELECT statement is to retrieve rows from one or more tables.  SELECT statements only return data from tables which you explicitly request to be queried.     If you don't specify that you wish to retrieve data from a referenced table using a JOIN, then any entries referenced through a foreign key constraint will be excluded by default from your results.