Ограничения внешнего ключа MySQL предотвращают запросы вставки в родительские таблицы - PullRequest
0 голосов
/ 08 октября 2018

У меня есть несколько таблиц MySQL InnoDB в моем проекте. Большинство запросов используют первичный ключ родительской таблицы в качестве основы для запроса, пример которого показан здесь:

Agreements (Parent Table)
---------------------------------------------------
ID       UnitID    Report   Protected   TenantID
---------------------------------------------------
19       288       1        0           13
20       287       1        0           9
21       286       1        0           9



Reviews (Child Table)
-----------------------------------------------------
ID    AgreeID     FrequencyID      ReviewDate
-----------------------------------------------------
10    11        4              2015-04-25 00:00:00             
14    35        4              2007-03-08 00:00:00     
15    18        4              2017-03-01 00:00:00



ActionableDates (Child Table)
------------------------------------------------------------
ID    AgreeID   CriticalDate           Note
------------------------------------------------------------
3     11        2013-04-24 00:00:00    ... yadda yadda ....
7     48        2017-11-25 00:00:00    ... yadda yadda ....
8     47        2014-05-21 00:00:00    ... yadda yadda .... 
9     14        2014-06-24 00:00:00    ... yadda yadda ....

Таблицы были перенесеныиз MS Access и ive провели последние несколько месяцев, написав приложение для клиента, которое в основном читает и обновляет данные.Это работает нормально, но теперь при попытке ВСТАВИТЬ новые записи ограничения внешнего ключа предотвращают любые вставки нового Соглашения (Родительская таблица), так как есть ограничения UPDATE / DELETE CASCADE для всех дочерних таблиц (Reviews и ActionableDates).

Agreements.ID -> Reviews.AgreeID
Agreements.ID -> ActionableDates.AgreeID

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

Логика заключается в том, что дочерние таблицы имеют записи, добавленные в любое время в течение срока действияоперативное применение;так что, если добавление нового соглашения, то, скорее всего, НЕ будет записи проверки для добавления в соответствующую таблицу отзывов.То же самое с таблицей ActionableDates.Эти «инциденты» происходят в любое время после создания Соглашения (записи).

Существуют ли какие-либо манипуляции с этими ограничениями MySQL, которые я могу использовать для сохранения обновления / удаления CASCADE ON, но который позволяет мне ввестиновая запись в родительской таблице ??Ни одно из других действий не может быть установлено без ошибки: «Нет действия», «Установить значение по умолчанию», «установить значение NULL» и т. Д. *

Не уверен, почему или как эти ограничения работали в исходной БД MS Accessно они не имеют смысла логически.Кроме создания фиктивной записи для дочерних таблиц ???

На данный момент я удалил все ограничения внешнего ключа и использовал Transactional PDOMySQL для определения некоторой логики.

Правка - Схема таблицы соглашений

Соглашения

+-----------------------------+-------------------------------+----------+---------+
| Column                      | Type                          | Nullable | Default |
+-----------------------------+-------------------------------+----------+---------+
| ID (PRIMARY)                | int(11)  Auto Increment       | No       |         |
+-----------------------------+-------------------------------+----------+---------+
| UnitID                      | int(11)                       | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| Report                      | tinyint(4)                    | Yes      | 0       |
+-----------------------------+-------------------------------+----------+---------+
| Protected                   | tinyint(4)                    | Yes      | 0       |
+-----------------------------+-------------------------------+----------+---------+
| TenantID                    | int(11)                       | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| RentNotes                   | longtext  utf8_general_ci     | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| Dilapid                     | varchar(255)  utf8_general_ci | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| AgreeDated                  | datetime                      | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| AgreeStartDate              | datetime                      | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+
| AgreeEndDate                | datetime                      | Yes      |         |
+-----------------------------+-------------------------------+----------+---------+

Ответы [ 2 ]

0 голосов
/ 08 октября 2018

В таблице Соглашения у вас есть

---------------------------------------------------
ID       UnitID    Report   Protected   TenantID
---------------------------------------------------

Вам необходимо проверить, где вы получаете Идентификатор объекта и TenantID, которые могут быть первичными ключами других таблиц, таких как «Объект» и «Арендатор».В этом случае вам нужно иметь записи в этих таблицах, тогда только вы можете ссылаться на них в этой таблице.

0 голосов
/ 08 октября 2018

Необходимо изменить внешние ключи.

Reviews.AgreeID         -> Agreements.ID
ActionableDates.AgreeID -> Agreements.ID

Таблицы child должны указывать на таблицу parent , а не наоборот

...