Почему заказу нужен устойчивый идентификатор
Представьте таблицу клиентов: у каждой записи есть уникальный номер, имя и адрес. В таблице заказов вместо полного набора этих данных хранится номер клиента. В реляционной базе данных — системе, где сведения размещены в связанных таблицах, — такой номер служит внешним ключом: он указывает, с какой записью клиента связан заказ.
Когда приложению нужно показать заказ вместе с именем покупателя, база выполняет соединение таблиц: находит строку клиента с тем же номером и временно объединяет сведения для ответа. Это не означает, что данные физически сливаются в одну таблицу: исходные записи остаются раздельными.
Что происходит при изменениях
Если клиент сменил адрес, его достаточно обновить в одной записи, а не искать и исправлять во всех заказах. Это снижает риск расхождений — например, когда в разных заказах одного человека случайно оказываются разные варианты адреса. Уникальный номер также помогает различать людей с одинаковыми именами.
Связь можно защитить ограничением целостности: база не позволит заказу ссылаться на несуществующего клиента. Тогда ошибка обнаружится при записи, а не позже — когда покупатель не появится в отчёте или заказе не удастся найти владельца.
Не всякий адрес следует менять задним числом
Разделение данных не решает вопрос, какой именно адрес нужен для старого заказа. Текущий адрес клиента может измениться, а для доставки важен адрес, указанный в момент покупки. Поэтому системы часто отдельно сохраняют адрес доставки в самом заказе как снимок на время оформления. Так текущие контактные данные можно обновлять, не переписывая историю уже совершённых покупок.
