Я знаю, как это сделать, см. ниже, но не знаю, почему? Для чего они нужны?
Ответ 3
Я думаю, вы запутались в двух разных проблемах, когда использовать InnoDB вместо MyISAM и когда использовать ограничения внешнего ключа (FK).
Что касается первой проблемы, было много ответов, которые отлично справляются с объяснением различий между MyISAM и InnoDB. Я просто повторю, что в цитате tvanfosson из статьи MyISAM лучше подходит для системы с главным образом чтениями. Это связано с тем, что вместо уровня строки, такого как InnoDB, используется блокировка на уровне таблицы, поэтому MyISAM не может обрабатывать также высокий concurrency, а также недостающие функции, которые помогают с целостностью данных, такими как транзакции и внешние ключи (опять же, уже упомянутые другими).
Вам не нужно использовать ограничения FK в вашей модели данных. Если вы знаете, каковы отношения между вашими таблицами, и ваше приложение не имеет ошибок, то вы обойдетесь без FKs просто отлично. Однако использование FK дает дополнительную страховку на уровне базы данных, потому что тогда MySQL не позволит вашему приложению вставлять плохие данные на основе созданных вами ограничений.
Если вам непонятно, зачем использовать первичные ключи (PK), создание столбца, такого как id_order
, например, PK таблицы orders
означает, что MySQL не позволит вам INSERT
одно и то же значение id_order
более одного раза, поскольку каждая строка в столбце PK должна быть уникальной.
A FK будет использоваться в таблице, которая имеет зависимость от другой таблицы, например, order_items
будет иметь зависимость от orders
(ниже). id_order_items
- это PK order_items
, и вы можете сделать id_order_items
FK таблицы orders
для установления отношения "один ко многим" между orders
и order_items
. Аналогично, id_item
может быть FK в таблице order_items
и PK в таблице items
для установления отношения "один ко многим" между order_items
и items
.
** Затем то, что делает ограничение FK, не позволяет вам добавить id_item value to the
order_items table that isn't in the
items table, or from adding a
id_order_items to
orders that isn't in the
order_items `table.
Все, что делает FK, обеспечивает целостность данных, а также помогает передавать отношения между вашими таблицами другим разработчикам, которые не записывали систему (и сами месяцы спустя, когда вы забыли!), но в основном это для целостности данных. * *
Дополнительный кредит: так зачем использовать транзакции? Ну, вы уже упоминали цитату, в которой говорится, что они полезны для банковской системы, но они полезны в других ситуациях, чем это.
В основном, в реляционной базе данных, особенно если она normalized, обычная операция, такая как добавление заказа, обновление заказа или удаление заказ часто затрагивает более 1 таблицы и/или включает более одного оператора SQL. Вы даже можете несколько раз коснуться одной и той же таблицы (как показано в примере ниже). Операторы Btw Data Manipulation Language (DML) (INSERT
/UPDATE
/DELETE
) включают только одну таблицу за раз.
Пример добавления заказа:
Я рекомендую таблицу orders
и таблицу order_items
. Таким образом, вы можете иметь PK на id_order
в таблице orders
, что означает, что id_order
не может быть повторено в orders
. Без отношения 1-to-many orders
- order_items
вам нужно будет иметь несколько строк в таблице orders
для каждого порядка, у которого было несколько связанных с ним элементов (вам нужна таблица items
тоже для эта система электронной коммерции btw). В этом примере будет добавлен порядок и прикоснитесь к двум таблицам при помощи 4 различных операторов INSERT
.
(никаких ключевых ограничений для иллюстрации)
-- insert #1
INSERT INTO orders (id_order, id_order_items, id_customer)
VALUES (100, 150, 1)
-- insert #2
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 1)
-- insert #3
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 2)
-- insert #4
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 3)
Итак, что делать, если запросы вставки # 1 и вставки # 2 успешно выполняются, но инструкция вставки # 3 не указала? Вы получили бы заказ, в котором отсутствовал элемент, и это были бы данные мусора. Если в этом случае вы хотите отменить все запросы, чтобы база данных находилась в том же состоянии, что и раньше, добавив заказ, а затем начинайте с того, что именно за транзакции. ** Вы группируете вместе запросы, которые вы либо хотите, чтобы все они сделали, или в случае исключения, а затем вообще ничего, в транзакцию.
Так как ограничения PK/FK, транзакции помогают обеспечить целостность данных. **