Вам понадобится немного более продвинутый, чем простой запрос, чтобы выполнить это. Я бы посоветовал вам нормализовать ваш дизайн, чтобы поместить номер и город в отдельную таблицу, а затем просто связать эту таблицу с двумя другими таблицами.
Как правило, вы не должны дублировать информацию более чем в одну таблицу. Однако есть исключения из этого.
Однако вы не просили совета, поэтому у вас могут быть причины сделать это так, как вы просили. Если это все еще путь, по которому вы хотите пойти, ваши параметры продиктованы тем, какой тип SQL вы используете. На многих платформах SQL это можно сделать с помощью хранимой процедуры. В некоторых вы можете использовать представление, триггер и хранимую процедуру. Я дам вам краткий обзор каждого варианта.
- хранимая процедура
Напишите одну или несколько хранимых процедур (возможно, по одной для вставки, обновления, удаления). Эти процедуры принимают ваши значения в качестве параметров. Затем процы запускают запросы для каждой из таблиц одну за другой.
- Хранимая процедура + Просмотр + Триггер
(Вы можете сделать это на сервере MS SQL, но я не уверен в других.) Здесь вы создаете одно представление, которое объединяет ваши две таблицы. (объединение ваших общих полей.) Это дает вам одно представление, которое в основном состоит из двух таблиц, объединенных вместе. Теперь, поскольку это представление основано на двух таблицах, оно становится не обновляемым. Однако вы можете прикрепить хранимые процедуры к представлению для операций вставки, обновления и удаления. Здесь вы делаете то же самое, что и в первом методе, вы создаете несколько процедур для фактического обновления данных в двух таблицах под представлением. Эти процедуры немного отличаются, потому что они должны быть спроектированы как триггеры. Затем вы присоединяете эти процедуры к триггерам вставки, обновления или удаления представления. Когда все сказано и сделано, вы сможете напрямую вставлять, обновлять или удалять данные в представлении и видеть изменения в базовых таблицах.
Если все это кажется действительно сложным, это потому, что так оно и есть. Если у вас есть другой вариант, например, нормализация структуры данных для решения проблемы, попробуйте сначала. Если у вас действительно нет выбора и триггеры доступны, 2-й вариант работает очень хорошо.