私はさまざまな不動産会社の複数のサイトを開発しようとしています。すべて同じHTML、セクションなどを共有しています。その違いはコンテンツ、特にプロパティにありますが、それらのプロパティのいくつかは他の企業と共有することができます。Djangoマルチサイト共有データベース
私は、同じデータベースを共有し、URLを使ってコンテンツを区別することを考えています。このようにして、私は会社ごとに1つではなく1つのプロジェクトしか使用できません。
誰もこの種のプロジェクトの推奨事項はありますか？
ありがとう、
私はそれをしました。
いいですか？はい、私の場合はそうでした。私は同じコンテンツを再利用しなければなりませんでした。コンテンツを変更したときは、すべてのページで変更する必要がありました。シンプルなサイトでは、3つの異なるプロジェクトでコンテンツを3回展開したり変更したりするのは難しいことです。しかし、単純なフロントエンドのページ（Djangoはほとんど必要ない）でうまく動作しますが、 "本当の" Webアプリケーションの場合は推奨しません。
何が壊れますか？あなたのページが共有するものを考え、問題があるかどうかを確認してください。
1）私が推測しているのは、ページにユーザーログイン機能（管理者ログイン以外）が必要な場合、それは問題です。まったくつながりません。もし企業がユーザーの個人的な詳細が彼らが思ったほどプライベートではないことが分かったら、あなたは多くの問題を抱えている可能性があります。そして、これまでに一度も訪れたことのないページにユーザーアカウントがどのようになってしまったのか、本当に手掛かりのないユーザーにとっても同じことが言えます。
2）URL。いくつかの特別なハッキングなしに、それぞれの会社に異なるものを置くことはできません。いずれかの企業が/about/を、もう1つが/company/ページを持っていれば、企業が次のページを要求したときにあなたの顔に爆発する悪いソリューションをハッキングし始めるでしょう。
3）ハードコードされたデータまたはデータベースの値に接続されている、ページ上のその他のもの。私。社会認証など
あなたはそれについて何ができますか？
私は最初のものを解決する上でヘルバウンドしている場合は、ここで私はどうなるのかです：
- ユーザモデルを上書きして登録ページ
についての情報を追加 - 各ページ
のためのユーザモデルのカスタムマネージャの作成 - 書きます現在のリクエストにページ固有のマネージャーのみを使用できるミドルウェア
まったく、私は何百万年もしません。あまりにもハッキリ、あまりにも脆弱な道。別のデータベースを作成するだけです。
2つ目の問題を解決するには、要求がどのドメインから来たのかを確認し、正しいURL設定を返すマルチホストミドルウェアを作成できます。 Sthはthisに似ています。あなたのニーズに書き換えて変更することは本当に難しいことではありません。
あなたのために決定することは不可能ですが、私はあなたに片方向またはそれ以上に行く前に考えることを与えました。がんばろう！
これが現実の世界であれば、企業間でデータベースを共有することは推奨されません。「コードコンベンション」のみでデータを漏洩させないようにすることです。あなたは本当にその種の責任を望んでいません。これらのサイトの1つを定義する単一の「プロジェクト」を構築することができます。そのプロジェクトの複数のインスタンスをクライアントごとに1つずつスピンアップするだけです。 – aruisdante