LINUX.ORG.RU
решено Форум — Development  

django импортировать модель с другой базы

 ,


0

1

Есть два app на разных базах. Как сделать так, чтобы можно было на app1 импортировать модель app2 и связать их. Возможно ли это?

т.е мы сейчас в app1

from app2.model(другая бд на другом сервере) import some

class Some(model.Model): 
    some = CharField(some)
    place = models.OneToOneField(
        app2.some,
        on_delete=models.CASCADE,
        primary_key=True,
    )
★★★★

Последнее исправление: bryak (всего исправлений: 1)

всё возможно. не совсем понятно только, что имеется в виду «два app на разных базах»

в любом случае, смотри в сторону настройки settings.DATABASES (хинт: там может быть больше одной базы данных) и мета-опций модели managed и database

upd: уже отредактировал ОП. теперь понятнее.

нет, так не получится. как ты представляешь себе энфорсинг внешнего ключа между базами данных (тем более они на разных серверах)? просто используй IntegerField, которое будет хранить айдишник записи в другой БД. а за целостностью придётся следить самому.

eternal_sorrow ★★★★★
()
Последнее исправление: eternal_sorrow (всего исправлений: 2)
Ответ на: комментарий от eternal_sorrow

просто завтра потребуется слить 2 базы и вдруг выяснится что там id пересекаются - стандартная беда. ...

demrnd
()
Ответ на: комментарий от eternal_sorrow

Если у вас слабая связанность - то вы однажды решите получить сумму 2-х баз Волгоград+Краснодар. И вот тут вас ждет забавная конвертация. А потом еще + Москва.... uuid 128-bit Много? не думаю....

demrnd
()
Ответ на: комментарий от eternal_sorrow

Я вот сейчас наблюдаю контору с очень большой нагрузкой. userid в integer. Будь это uuid можно было бы запустить 1000 постгресов и паралельно слать им запросы - и получить почти линейную масштабируемость. Везде где вы используете 2 БД общие id лучше uuid. Хотя https://cs5.pikabu.ru/post_img/2015/12/04/5/1449210847155432089.jpg

demrnd
()
Ответ на: комментарий от demrnd

да причём тут это вообще? в данном случае нам нуждно просто каким то образом обеспечить отношения one-to-one между двумя разными таблицами в разных базах. семантически разными. зачем uuid? создаём в одной из таблиц поле того же типа, что и primary key во второй таблице и вносим туда pk соответствующих записей. всё. никаких uuid городить не нужно, он здесь лишняя сущность

eternal_sorrow ★★★★★
()
Ответ на: комментарий от eternal_sorrow

Еще раз если у тебя 2 БД - то ты с integer получишь проблемы. Тут нужны распределенные транзакции и оркестровка. Рано или поздно ты с integer влетишь. Но яж сказал «и так сойдет».....

demrnd
()
Ответ на: комментарий от demrnd

нужны распределенные транзакции и оркестровка

нужны ли?

eternal_sorrow ★★★★★
()
Ответ на: комментарий от eternal_sorrow

Есть 2 базы. 2 таблицы с первичным ключем. Пусть 1 на постгрес, а вторая mysql. Ты делаешь insert - что вставишь первичным ключем?

demrnd
()
Ответ на: комментарий от demrnd

стандартно. делаем insert в первую базу (со стандартным AutoField в качестве первичного ключа), берём первичный ключ, с ним делаем insert во вторую базу.

eternal_sorrow ★★★★★
()
Ответ на: комментарий от eternal_sorrow

Ага. А потом удаляем - получаем повторное использование. А потом спустя пол года кто нибудь добавит autofield (так ведь удобно...) И потом все накроется. Еще раз uuid придумали для общих ключей. И вообще завтра может смениться порядок куда сначала инсертим?

demrnd
()
Ответ на: комментарий от demrnd

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

eternal_sorrow ★★★★★
()
Ответ на: комментарий от eternal_sorrow

решать в любом случае разработчику исходя из имеющейся у него информации.

2 руками за. Но за годы моей работы я встречал сотни случаев - «блин, а чтож ты сразу не подсказал».... Потому я ТС и намекаю - лучше погляди на UUID... Кроме выгоды почти ничего плохого нет.

demrnd
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development