モデルを複製することで、メインのdjangoプロジェクトから別のdjangoプロジェクトに重いプロセスの一部を移したいと思います。
これは、データベーステーブルの共有を意味します。これは、テーブルがどのように共有されるかを説明する図です。番号付きの矢印に従って、情報の流れをどのように想像するかを確認してください。
INTERFACEプロジェクトは、パズルのユーザーインタラクション部分であり、入力と出力を処理し、ユーザーが解決したい問題を定義します。SOLVEプロジェクトは、ユーザー定義の重い問題を解決し、準備ができたら、ソリューションをレコードとして、INTERFACEが読み取ることができる独自のテーブルに配置し、INTERFACEがユーザーに提示します。
この設計には、2つのORMの同期に関してどのような警告がありますか？これもいい考えですか？
言い換えれば、あなたはタスクキューを再発明しているのですか？
つまり、インターフェイスは「これを実行してください」を表すレコードを挿入するだけで、後で「これはあなたのために実行されました」テーブル（または同じテーブルは関係ありません）から結果を取得しますか？
あなたが本当に探しているのは、ある種のリモート非同期rpc呼び出しインターフェースです。そうです、気が向いたら、この方法で再構築できます。
セロリの再評価をお勧めします。何度か延期しましたが、設定したので、以前は使用していなかったのでショックを受けました。Django DBをメッセージキューのバックエンドとして使用することもできます（ただし、ボリュームの少ないサイトでのみ使用すると言います）。
とにかく、特定の質問に関して：
同じDBテーブルを使用する2つの独立したプロセスに継承の問題はなく、Djangoもdbコネクタもこの点で追加の制約を追加しません。
実行するタスクを探してDBを定期的にポーリングするか、メッセージを送信するために、ワーカープロセス（「解決」）が必要になります（ヒント：セロリ！）。uiクライアント（「インターフェース」）は、ユーザーが更新したときにDBをチェックするだけです。
実装の観点からは、両方のプロジェクト間でコードを完全に（すべてのモデル、ビューなど）共有するのがおそらく最も簡単です。通常の方法でUIWebサーバーを起動するプロセスが1つあります。ワーカーの場合、カスタム管理コマンドをフックするのが、ワーカーのループを開始する最も簡単な方法です。
行に書き込むときにselect_for_updateを使用しないと、dbロック/競合状態で問題が発生する可能性があります。または、 .save（update_fields = zzz）を使用して競合を回避することもできますが、これは1.5のみです。