Вы неправильно поняли, что такое внешние ключи.Они не являются волшебным способом добавления данных в более чем одну таблицу.Это ограничение .Они ограничивают значения, которые могут отображаться в столбце access_codes.id_fk.В этом случае допустимы только значения, указанные в столбце codes.id.Но не будет новой строки, вставленной в access_codes каждый раз, когда новая строка будет вставлена в codes.Вам придется сделать это самостоятельно.
На заметку - не проще ли в этом случае хранить все данные в одной таблице?
Добавлено: Ускоренный курс по ключам базы данных
Давайте начнем с Первичные ключи , это полезно.Большинство СУБД этого дня и возраста рассматривают таблицы как большие группы строк.Строки не упорядочены (каждый раз, когда вы выполняете select * from mytable, вы можете вернуть их в другом порядке), и нет ничего, что отличало бы их друг от друга.Например, если вы бросите 100 зеленых шариков в ведро, вы не сможете определить, какой именно это шар.Если вы хотите отличить их друг от друга, вам нужно присвоить каждому шару какую-то уникальную отметку, например, написать разные цифры на каждом или чем-либо.
При работе с базами данных мы обычно хотим разделять наши строки.Всякий раз, когда мы что-то делаем с таблицей, мы обычно хотим обновить или удалить в ней определенные строки, поэтому нам нужна эта уникальная идентификационная метка.Создатели механизма базы данных признают это, и большинство СУБД в наши дни предлагают две важные функции - первичные ключи и столбцы auto_increment (хотя имена этих функций могут меняться от DB к DB).
Когда вы помечаете столбец какСтолбец «Первичный ключ», это означает, что этот столбец будет содержать уникальный идентификатор для каждой строки.Механизм БД не позволит вставить две строки с одинаковым значением в столбец первичного ключа (или обновить строку, чтобы сделать это так), поскольку цель этого столбца - уникальная идентификация каждой строки.Наличие двух строк с одним и тем же идентификатором отрицательно скажется на этой цели.
Обратите внимание, что в качестве первичного ключа вы также можете использовать несколько столбцов.В этом случае значения в каждом столбце не обязательно должны быть уникальными, но комбинация значений в каждой строке должна быть уникальной среди всех строк в таблице.
Кроме того, вы можете иметь другие «уникальные»"столбец (столбцы), если вам нужно - есть даже" уникальный индекс ", который снова заставляет БД отказываться вставлять строки с неуникальными значениями.
Но Первичный ключ - особенный.Во-первых, потому что он сообщает любому, кто смотрит на таблицу, «это официальный способ разделения этих строк», а во-вторых, потому что большинство СУБД фактически хранит строки на диске в том же порядке, что и Первичный ключ.Это означает, что поиск строки, если вы знаете, что это значение Первичного ключа, очень быстрый.
Таким образом, большинство людей просто используют Первичные ключи для идентификации строк, а другие уникальные индексы встречаются довольно редко (хотя они случаются со временемна время).
Auto_increment - это функция, которая помогает генерировать эти уникальные идентификаторы.Если вы пометите столбец (обычно целочисленный / числовой) как «auto_increment» (некоторые РСУБД позволяют пометить только один столбец на таблицу), то при вставке новой строки столбец автоматически получит значение, которое на 1 больше, чем предыдущее наибольшее значениев этой таблице.Уникальные идентификаторы стали проще.
Теперь о Иностранных ключах .
Снова довольно часто нам нужно связывать две строки (обычно в разных таблицах, но иногда в одной и той же).таблица) вместе почему-то.
Например, наша компания производит программное обеспечение, связанное с оплатой парковки.Итак, у нас есть таблица, в которой перечислены все машины, которые в данный момент где-то припаркованы.Каждый ряд представляет собой припаркованный автомобиль.Он содержит номерной знак, когда началась парковка, йадда йадда.Затем у нас есть еще одна таблица, в которой перечислены все наши клиенты - имена пользователей, хэши паролей, номера телефонов, электронные письма, работы.Каждая строка представляет одного клиента.В другой таблице перечислены все парковки, где мы работаем.Один ряд на парковку.Имя, адрес, координаты GPS, описание, цены и т. Д.
Каждая из этих таблиц имеет столбец auto_increment ID, который также является первичным ключом.
Теперь в первой таблице- тот, который перечисляет, какие машины припаркованы - для каждой машины мы также хотим знать, какой клиент ее припарковал и на какой парковке.Таким образом, у нас есть два столбца - client_id и lot_id.В столбце client_id мы сохраняем значение для ID таблицы клиентов, а в lot_id сохраняем значение для таблицы лотов.
Так, например, если мы видим, чтомашина с табличкой AB1234 припаркована и принадлежит клиенту с идентификатором 222, затем мы можем перейти к таблице клиентов, найти строку с идентификатором 222 и увидеть, что это Джон Смит.Точно так же мы можем искать конкретный лот, так как мы знаем его значение идентификатора.
Это все, что есть для внешних ключей - это просто идея поместить уникальный идентификатор одной строки в другую строку, чтобы вы могли знатькакая строка относится к какой строке (кроме того, именно отсюда происходит «реляционная» часть в «реляционных базах данных»).
Теперь нужно рассмотреть еще одну вещь - ограничения внешнего ключа - это потрясающая особенность от создателей RDBMS.Вы не обязаны строго использовать его, но я рекомендую его вам.Это так хорошо.
По сути, это то, что вы можете сказать СУБД, что «этот столбец в этой таблице на самом деле является внешним ключом для этого столбца в этой таблице».И тогда БД поможет вам позаботиться о том, чтобы все выровнялось.
Например, я не смогу вставить припаркованный автомобиль для клиента 222, если нет клиента с идентификатором 222 в таблице клиентов.И если я попытаюсь удалить клиента 222, он не позволит мне это сделать, потому что для него все еще припаркована машина.Другими словами, он гарантирует, что независимо от того, какую строку я выберу из таблицы припаркованных транспортных средств, если я затем возьму идентификатор клиента из этой строки, ВСЕГДА БУДЕТ строка в таблице клиентов, соответствующая этому идентификатору.В аду нет способа, как я могу обойти это.И это предотвращает много головных болей в будущем.