Понимание / MySQL ака обманывает отношения ForeignKey в Django - PullRequest
3 голосов
/ 22 июля 2011

Итак, я унаследовал некоторый django.

Таблица mySQL достаточно проста, где parent - это НЕ отношение FK, а просто идентификатор "Parent":

CREATE TABLE `Child` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `parent` int(10) unsigned NOT NULL,
  `name` varchar(255) NOT NULL,
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=24;

Но тогда инициаторсделал это ..

class Child(models.Model):
    """Project Child information"""
    id = models.AutoField(primary_key=True)
    parent = models.ForeignKey(Parent)
    name = models.CharField(max_length=255)

    class Meta:
        managed = False

По общему признанию, я НЕ SQL-жокей, но я знаю, что "реальная" связь с внешним ключом выглядит подобно этому уведомлению CONSTRAINT ...

CREATE TABLE `Child` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) NOT NULL,
  `name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  KEY `child_63f17a16` (`parent_id`),
  CONSTRAINT `parent_id_refs_id_34923e1e` FOREIGN KEY (`parent_id`) REFERENCES `Parent` (`id`)
) ENGINE=InnoDB;

Я хочу знать следующее:

  1. Какие проблемы я мог бы ожидать увидеть с помощью этого "обмана".
  2. Хотя это работает, рекомендуется или рекомендуется.
  3. Не советуем ли нам изменить SQL на , добавить в ограничение ?

Большое спасибо!

Ответы [ 2 ]

1 голос
/ 22 июля 2011
  1. Отсутствие фактического ограничения может привести к неправильным ссылкам, неверным родителям и другим видам несоответствий данных.Я не эксперт по Django, но рискну предположить, что в большинстве случаев Django все равно будет корректно обрабатывать отношения, если вы не намеренно добавите несколько недопустимых записей.

  2. Обычно, если ваша СУБД поддерживает иностранныеключевых ограничений, нет абсолютно никаких причин не использовать их, и потенциально можно было бы считать недостаток проекта, чтобы игнорировать их.

  3. Вы должны рассмотреть возможность добавления ключевых ограничений.Они не только дают вашей СУБД хорошее представление о том, как оптимизировать запросы, но и обеспечивают согласованность ваших данных.Я почти уверен, что у Django есть настройка где-то, которая будет автоматически генерировать SQL для добавления ограничений ключа при запуске manage.py syncdb

Для получения дополнительной информации о том, почему вы предпочитаете внешние ключи, выследует прочитать Документация по внешнему ключу MySQL

Самое интересное:

InnoDB требует индексов для внешних ключей и ссылочных ключей, чтобы проверка внешних ключей могла быть быстрой и нетребуется сканирование таблицы.В ссылочной таблице должен быть индекс, в котором столбцы внешнего ключа перечислены как первые столбцы в том же порядке.Такой индекс создается в ссылочной таблице автоматически, если он не существует.(Это отличается от некоторых более старых версий, в которых индексы должны были создаваться явно, иначе создание ограничений внешнего ключа не удавалось.) Index_name, если задано, используется, как описано ранее.

0 голосов
/ 22 июля 2011

Предполагается, что это быстрее ... так как вы mysql не проверяете ограничение перед добавлением строки в дочернюю таблицу. Но с внешним ключом это сделает вашу жизнь проще, так как вы можете использовать при обновлении и при удалении. Я бы пошел с ограничением.

...