как обновить один и тот же столбец в более чем одной таблице

Question

Я хочу узнать, как обновить один и тот же столбец в более чем одной таблице в одной и той же базе данных sql, но эти таблицы связаны друг с другом через этот столбец, который является первичным ключом в одной и forgin ключ в других таблицах с C # пожалуйста, помогите мне

Answer 1

То, что вы хотите, может быть указано в ограничении внешнего ключа. Проверьте здесь, например Синтаксис MySQL .

Нечто подобное должно работать и для вашего sql-диалекта.

[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
  REFERENCES tbl_name (index_col_name, ...) ON UPDATE CASCADE

CREATE TABLE Parent(
  PID SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
  Name VARCHAR(20),
  PRIMARY KEY (PID)
);

CREATE TABLE Child(
  CID SMALLINT UNSIGNED NOT NULL PRIMARY KEY,
  PID SMALLINT UNSIGNED NOT NULL,
  FOREIGN KEY (PID) REFERENCES Parent (PID)
    ON UPDATE CASCADE
);

INSERT INTO PARENT (Name) VALUES ('Joe');
INSERT INTO PARENT (Name) VALUES ('Max');
INSERT INTO Child (CID, PID) VALUES (1, 1);
INSERT INTO Child (CID, PID) VALUES (2, 2);

SELECT * FROM Parent;
SELECT * FROM Child;

Parent             Child
+------+------+    +------+------+
| PID  | Name |    | CID  | PID  |
+------+------+    +------+------+
| 1    | Joe  |    | 1    | 1    |
+------+------+    +------+------+
| 2    | Max  |    | 2    | 2    |
+------+------+    +------+------+

UPDATE Parent SET PID='5000' WHERE PID='1';
SELECT * FROM Parent;
SELECT * FROM Child;

Parent             Child
+------+------+    +------+------+
| PID  | Name |    | CID  | PID  |
+------+------+    +------+------+
| 5000 | Joe  |    | 1    | 5000 |
+------+------+    +------+------+
| 2    | Max  |    | 2    | 2    |
+------+------+    +------+------+

В этом примере может возникнуть проблема в зависимости от вашей DB-системы. Если система БД не проверяет, назначен ли уже PID, когда в «Режиме AUTOINC» в какой-то момент значение автоинкремента может достигнуть 5000, и вставка может завершиться неудачно, поскольку уже есть строка с этим PID. Зависит от того, как ваша DB-система обрабатывает изменение столбца первичного ключа, когда задано автоматическое увеличение

Answer 2

Что вы хотите ответить на свой вопрос, это внешний ключ с каскадным обновлением, как указано в ответе от джиттера. Однако, как и большинство других соображений, вам не придется задавать этот вопрос, если вы вернетесь назад и проанализируете основную потребность в выполнении операций такого типа.

Хотя это работает, это означает, что первичный ключ на объектах вашей базы данных ненадежен с течением времени, а также означает, что базе данных, возможно, придется выполнить огромный объем работы, выполняя каскад (и он должен будет поддерживать больше блокирует выполнение такого обновления, что увеличивает вероятность блокировки).

Что касается надежности с течением времени, скажем, у вас есть склад, который поддерживает исторические сальдо по счету: AcctPK, EffectiveDate, Balance, теперь у вас потенциально может быть большое количество строк для каскадного обновления если вы добавите это как еще одно каскадное отношение FK в вашу БД. Если хранилище данных находится в отдельной базе данных, вы не можете применить ссылочную целостность, поэтому каскад не происходит, и теперь у вас больше нет непрерывности учетной записи, которая была до изменения AcctPK.

Предположим, вы экспортируете данные поставщику, который предоставляет услугу какой-либо информации для каждой строки. Теперь, когда поставщик возвращает результаты, вы не можете сопоставить некоторые строки, поскольку отправленный вами PK больше не существует в ваших данных.

В обоих этих случаях вы можете обойти эту проблему, сохраняя записи об изменениях PK с течением времени, но в конечном итоге все сводится к обходу (вероятно) неудачного выбора PK.

Я настоятельно рекомендую вам пересмотреть выбор первичного ключа, если он будет часто меняться. Одной из альтернатив будет использование суррогата IDENTITY или автономного номера в качестве PK (вместо этого основывается отношение FK). Это никогда не потребует каскадного обновления, и другое поле, которое вы в настоящее время используете в качестве «естественного» первичного ключа, может быть изменено в обычном UPDATE без необходимости делать каскад.

Answer 3

Изменение первичного ключа никогда не бывает увлекательным: поэтому многие люди предпочитают синтетический натуральным ключам. Не существует стандартного SQL-способа с одним оператором; вместо этого вам нужно ВСТАВИТЬ копию строки основной таблицы с новым первичным ключом, ОБНОВИТЬ дочернюю таблицу (таблицы), чтобы сослаться на новую строку, и УДАЛИТЬ исходную строку.