Vampireofdarkness
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.
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The non-simplified version would check by ID, not by 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.
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).
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).
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.