Django или аналогичный для составных первичных ключей

Я пишу веб-приложение для своей инженерной компании (предупреждение: я программист только по хобби) и планировал использовать Django, пока не ударил эту загвоздка. Модели, которые я хочу использовать, имеют первичные ключи с несколькими столбцами. Per http://code.djangoproject.com/ticket/373, я не могу использовать Django, по крайней мере, не выпущенную версию. Может ли кто-нибудь помочь мне с обходным путем, будь то через другую веб-инфраструктуру (только на основе Python, пожалуйста) или предлагая изменения в модели, чтобы она работала с ограничениями Django? Я действительно надеюсь на последнее, поскольку я надеялся использовать это как возможность изучить Django.Django или аналогичный для составных первичных ключей

Пример: В таблице 1 есть part_number и part_revision как два поля, которые должны содержать первичный ключ. P/N может существовать при нескольких ревизиях, но P/N + rev уникальны.

В таблице 2 в качестве первичного ключа есть part_number, part_revision и size_number. P/N при определенном обороте может иметь ряд измерений, однако каждый из них уникален. Кроме того, в этом случае P/N + rev должен быть ForeignKey таблицы 1.

источник

2009-10-26 Matthew DeNardo

Работает над созданием суррогатного ключа (столбца автоматического увеличения) в качестве столбца первичного ключа и размещения уникального индекса на сводном ключе домена.

Внешние ключи будут ссылаться на суррогатную колонку первичного ключа.

источник

2009-10-26 11:27:24

+1 - Бей меня к нему. –

Почему бы не добавить обычный первичный ключ, а затем указать, что part_number и part_revision как unique_together?

Это, по сути, способ Djangoish (Djangonic?) Делать то, что сказал Митч Пшени.

источник

2009-10-26 11:29:19

Вау! это на самом деле лучшее решение! –

Djangonic в соответствии с Pythonic :) – ajay

Я настоятельно рекомендую использовать суррогатный ключ. Не потому, что это «Djangoesque». Предположим, что вы используете составной ключ, который содержит part_number. Что, если через некоторое время ваша компания решит изменить формат (и, следовательно, значения) этого поля? Или, в общем, любое поле? Вы не хотели бы иметь дело с изменением первичных ключей. Я не знаю, какую пользу вы видите при использовании составного ключа, который состоит из «реальных» значений, но я считаю, что это не стоит хлопот. Используйте бессмысленные, автоинкрементные ключи (и это, вероятно, должно сделать составной ключ бесполезным).

источник

2009-10-26 12:37:23 shanyu

Это должно быть сильно изменено. Хорошая статья о том, почему суррогаты являются лучшей идеей: http://www.agiledata.org/essays/keys.html – cethegeek

Большая проблема в индустрии программного обеспечения заключается в том, что каждый пытается исправить данную проблему в большем масштабе. Что, если я, с другой стороны, пытаюсь применить Django к предопределенному набору данных, структура которого может быть изменена или не изменена? Что еще более важно, так это то, что это один из вариантов использования самого Django: «рамки для перфекционистов с предельными сроками». –

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

источник

2009-10-26 13:13:31

, если вы хотите только уникальные смешанные поля:

class MyTable(models.Model): 
    class Meta: 
     unique_together = (('key1', 'key2'),) 

    key1 = models.IntegerField() 
    key2 = models.IntegerField()

Но если вы хотите уникальный вместе и один из колонки быть первичным попробовать аналогичный ниже код:

class MyTable(models.Model): 
    class Meta: 
     unique_together = (('key1', 'key2'),) 

    key1 = models.IntegerField(primary_key=True) 
    key2 = models.IntegerField()

источник

2016-11-25 19:16:17 Mohsen

Django или аналогичный для составных первичных ключей

ответ

Смежные вопросы