设置MySQL外键和索引-迁移到InnoDB

Question

I need help setting up foreign keys for migrating to InnoDB. The situation is that I have 3 tables: jobs, customers and contacts.

A job belongs to a Customer and a job belongs to a Contact. A Customer has many jobs and has many contacts. A contact belongs to a Customer and has many Jobs. I need help setting up foreign keys in the jobs table so that only Contacts that belong to a selected Customer can be inserted. (ie If Customer A has contacts A1 and A2 and Customer B has contact B1, once you select Customer A as the customer for a job, it will reject entries for Contact other than A1 or A2). Is this possible to do with foreign keys or will I have to do the verification in the programming language of my choice?

Here's my schema:

CREATE TABLE jobs(
  job_id INT(11) NOT NULL AUTO_INCREMENT,
  customer_id INT(11) DEFAULT NULL,
  contact_id INT(11) DEFAULT NULL,
  job_number INT(11) UNSIGNED NOT NULL DEFAULT 0,
  status_void TINYINT(1) DEFAULT 0,
  PRIMARY KEY (job_id),
  INDEX active_jobs (job_number, status_void),
  INDEX customer_id (customer_id),
  UNIQUE INDEX job_number (job_number),
  CONSTRAINT FK_jobs_contacts_contact_id FOREIGN KEY (contact_id)
  REFERENCES contacts (contact_id) ON DELETE SET NULL ON UPDATE CASCADE,
  CONSTRAINT FK_jobs_customers_customer_id FOREIGN KEY (customer_id)
  REFERENCES customers (customer_id) ON DELETE SET NULL ON UPDATE CASCADE
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;`

CREATE TABLE customers(
  customer_id INT(11) NOT NULL AUTO_INCREMENT,
  inactive TINYINT(1) DEFAULT 0,
  customer_name VARCHAR(50) NOT NULL DEFAULT '',
  PRIMARY KEY (customer_id),
  UNIQUE INDEX customer_name (customer_name),
  INDEX inactive (inactive)
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

CREATE TABLE contacts(
  contact_id INT(11) NOT NULL AUTO_INCREMENT,
  customer_id INT(11) DEFAULT NULL,
  inactive TINYINT(1) DEFAULT 0,
  first_name VARCHAR(50) DEFAULT NULL,
  last_name VARCHAR(50) DEFAULT NULL,
  PRIMARY KEY (contact_id),
  UNIQUE INDEX contact_key (customer_id, last_name, first_name),
  INDEX customer_id (customer_id),
  INDEX inactive (inactive),
  INDEX name (last_name, first_name),
  CONSTRAINT fk_contacts_customers_customer_id FOREIGN KEY (customer_id)
  REFERENCES customers (customer_id) ON DELETE RESTRICT ON UPDATE CASCADE
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

Another goal I have is to setup indexes to make listing all jobs that are not void (status_void=0) and all customers and contacts that are not inactive(inactive=0). I don't know if a multi-column index (jobs) or two separate indexes (customers/contacts) would help in this case.

Please take it easy on me as I'm still learning. Thank you for your time.

Answer 1

Is this possible to do with foreign keys or will I have to do the verification in the programming language of my choice?

Yes and yes.

This is the referential integrity that FKs add to your data. However if you do not also account for it in your application, you would present a horrible user experience that would allow a user to enter contacts that don't belong to a customer and after submitting that to the DB getting an error. It would be better to account for this in you application to prevent that situation from ever being sent to the DB, and the FK is kind of a back-up in case that somehow gets through.

Another goal I have is to setup indexes to make listing all jobs that are not void (status_void=0) and all customers and contacts that are not inactive(inactive=0). I don't know if a multi-column index (jobs) or two separate indexes (customers/contacts) would help in this case.

Which indexes to build tends to be query specific. So you would want to show an example query to best get advice in indexing, not just what your end goal is. It's important to know that only one index can be used for each table reference in a query. So if a table has multiple filters in the where clause you tend to get the best performance by having a multi-column index.

When planning your indexes it's a good idea to think about which columns have fewer unique values that would filter out a larger number of rows and list those first in the index.

All of that being said, without a representative query and the results of an explain statement on it, an outsider can't do much to advise you on indexes as their effectiveness is dependent on the data they are being used against.