Link to home
Start Free TrialLog in
Avatar of Vampireofdarkness
VampireofdarknessFlag for United Kingdom of Great Britain and Northern Ireland

asked on

MySQL FOREIGN KEY vs JOIN Benchmark

Question, in a nutshell: At what point do FKs start/stop outperforming JOIN statements? Yes they are two different functions, but they give the same end result for the situation below.

MySQL 5.0.51, PHP 5.2.6, Apache 2.2

---

I had a thought last night before bed and I haven't had a chance to set something up yet to test this, so I thought I'd ask here and see if anyone has done, or read something similar in the past.

I have several tables in a database all set up lovely. One is customers (id, name, postcode), one is supplier (id, name, telephone) and one is stock (id, name customer, supplier). This has simplified it greatly -- each table actually has somewhere around 20 fields for various bits of information.

Stock has around 8,000 entries; Customers has around 9,000 entries and Supplier has around 40 entries. stock.supplier is linked by FK to supplier.name; stock.customer is linked by FK to customers.name;

Customer names very rarely change (maybe one to five times per year) and supplier names never change -- because of this I think FK is the best route; However, are FKs in this instance going to outperform JOINing SQL statements? In my head it makes less overhead selecting from two / three tables for each stock item called (probably 1,000/day) with the added benefit of easier, simpler queries.

The downside is larger database tables (rather than storing customers.id and supplier.id in the stock.x fields, it has the name).

I know for tables of this size, and usage this low it probably isn't going to matter much.

Hope this makes sense. If no answers before I get a chance to set up a sim, I'll post my results.
ASKER CERTIFIED SOLUTION
Avatar of Guy Hengel [angelIII / a3]
Guy Hengel [angelIII / a3]
Flag of Luxembourg image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of greisch
greisch

It's bad design to use something that can change as a key (even a foreign key).
So you should replace the customer name by costomer id and supplier name by supplier id in the stock table and join the tables to find names back.
Avatar of Vampireofdarkness

ASKER

The non-simplified version would check by ID, not by name
The downside is larger database tables (rather than storing customers.id and supplier.id in the stock.x fields, it has the name).

I perhaps didn't make it clear enough, but if using FK it will have both id and name. ID for referencing back if more information is needed, name for not having to use a join to get the name where required. All functionality at the moment is based on IDs that never change.
I would not use Foreign Keys. I have always found that JOINs work very well as long as every column in the JOJN's ON clause is indexed as well as every column in a WHERE clause. That is the show-stopper, fail to index the correct columns and you might as well just not bother running the query.
It's always a bad idea to duplicate information.
It's always a bad idea to use field that can change to link tables, with or without foreign key. Because if you change the value in one table you have to change it in all the other tables where it's used.

FK express a constraint between tables. JOIN is used to retreave data.

You don't need to use FK. But, as bportlock said, the fields used to join tables should be indexed (performance).