ただし、開発の開始前であっても、クライアントの可能性のある要望を推測し、仕事を始める前に決定を下す必要があることをすぐに説明しようとすると、状況は大幅に改善されます。それには多くの時間がかかります。
オンラインストアのデザインを議論するときにすぐに考慮すべきことを見てみましょう。
Python / Djangoでオンラインストアを作成するとします。
א。 製品データの保存
多くのオンラインストアは、互いに大きく異なる製品を販売しています。 たとえば、電気ケトル用のパラメーターの1つのセット、ディルド用の2つ目のパラメーター、 一時的な刺青用のヘンナ用の3つ目のパラメーターがあります。 さらに、これらの製品はすべて同じサイトで販売できます。 または、さらに可能性が高い-商品と同じデータベースを使用する異なるサイトで（クライアントは、すべての店舗のすべての商品を共通の管理インターフェースから管理したい場合があります）。
したがって、通常、商品はパラメータの動的なセットを設定できるはずです。
MongoDB （または他の非リレーショナルDBMSから選択できます）を使用できます。 ここには多くのオプションがあります（これについてはよく議論されています。たとえば、 ここは softwaremaniacsのトピックの1つです）-いくつかはMongoクエリ言語の使用を提案し、いくつかはORMを使用する機会を残しています（ただし、これは疑わしい解決策であるという意見があります）。 もちろん、管理パネルにこのデータの制御を追加するには、ここでタンバリンとのいくつかのダンスが必要です。 一般に、タスクはそれほど難しくありませんが、独自のニュアンスが非常に多く存在する可能性があるため、リードタイムを事前に予測することはかなり困難です。
しかし、そのような目標が設定されていない場合、つまり、商品を追加および編集するメカニズムがなく、標準の管理パネルに存在するふりをしていない場合（可能であればインターフェースを調整する必要があります）、このオプションは最も便利で機能的に最適ですスケーリング（つまり、より多くの商品に関する情報を保存する必要があり、ストレスに対する耐性を改善する場合、変更を少なくする必要があります）。
もう1つのオプションは、Djangoの最も標準的なすべてを使用することです。 特に、 django ‑ eavがあります。 これは、モデル内のオブジェクトに動的なフィールドセットを追加できるソリューションです（もちろん、データは1つのテーブルに格納されません-データベースはリレーショナルのままです）。
この場合、管理パネルとすぐに統合できます。
しかし、すべてがそれほどスムーズではありません：まず、このオプションはパフォーマンスの点ではあまり良くありません（つまり、システムのスケーリングをすぐに複雑にします-したがって、これは高負荷が予想されない場合により適しています）、そして、多言語の実装における追加の困難。
一般的に、 Ivan SagalaevはEAVについて次のように書いています。
EAVは、属性セットが厳密に設定されていないか、単に非常に大きい場合です。 データベースに数千のテーブルがあり、各テーブルには1つの列があり、数千のレコードがあり、そのうち1つまたは2つが満たされているのはあまりクールではありません。
したがって、EAVが必要な場合、継承は役に立ちません。 一方、そのようなシステムを使用することはあまり便利ではありません。 ORMはこれを明示的にサポートしていません。実際、純粋に構造上、このようなテーブルへのクエリを作成することは難しく、動作が遅くなります。 それが理由で、システムがこのアプローチを必要とするなら、これは本質的にリレーショナルストレージを使用するのが不便であることを意味すると信じてきました。 そして、ドキュメント指向のデータベース（最も印象的な例としてはCouchDB）に目を向けるとよいでしょう。 しかし、これには意識を変え、関係慣行を放棄するために多くの努力が必要です。
これらの目的でDjangoをMongoDBで使用することについて何か話はありましたか？ 一般に、 はい 。 Alix Axelユーザーの答えには、電子商取引にMongoDBを使用する機能を明らかにするいくつかの優れたリンクがあります（ このプレゼンテーションへのリンクなど）。 ただし、Django向けの特定のソリューションは提供されていません。
EAVとhstoreの使用についてもう少し説明します（これは、PostgreSQLの動的な値のセットを保存するオプションです）。
検索と、オブジェクトとの直接接続があります。 当然、選択は速すぎることはありませんが、小さな店ではこれは問題になりません。
-hstoreについてのGrigory Fateyevについては、こちらから 。
インターネットでは、動的フィールドを実装するさまざまな方法に関する多くの情報を見つけることができます。 たとえば、 ここにStackoverflowに関する別の説明があります。
ב。 多言語
多言語コンテンツの実装にはさまざまなソリューションがあります-この場合、特に、商品に設定されているパラメーターの異なる言語への翻訳。 ただし、データストレージに使用する方法によっては、これらのアプリケーションが適切でない場合があります（ただし、いずれかを適応させることはできます）。
ג。 履歴を編集
多くの場合、各製品の編集履歴はクライアントにとって非常に役立ちます（たとえば、そのように編集されていない場合に何かを復元するため）。
リレーショナルデータベースでは、これは既製のアプリケーションの 1つを使用して行われます 。
たとえば、 django‑reversionは、 django‑reversion -compareを使用してdiffを表示できます（ページをスクロールしてください-スクリーンショットがあります）。
django歴史もあります-Uilda開発者ildusの仕事です。 django –復帰、django –改訂、およびdjango – simple–履歴のレビューを次に示します。
非リレーショナルデータベースを使用する場合は、もちろん、もう少し複雑です。 一般に、フィールドの動的セット+翻訳の動的セットは、Mongoを使用することを支持する非常に説得力のある引数ですが、私には思えます。 結局、そのような「埋め込み」データを格納するために存在します（さらに、値を便利にグループ化することが可能になります！）。 ここでの唯一の反論は、おそらく既存のeコマースソリューションとの統合が困難になる可能性があることです。 一方、これにより、いずれにしても、比較的複雑なプロジェクトの開発は困難になり、これまでのところ完全に回避することはできません。
ד。 製品カテゴリー
ほとんどの場合、商品にはツリーカテゴリが必要です。つまり、各カテゴリには商品だけでなく、いくつかのレベルのネスト（たとえば、オーディオ→ヘッドフォン→開く）を含めることができます。
ところで、 ここでは Djangoでオブジェクトのそのような階層を実装するための良い議論があります（ django ‑ mpttに言及する以外に、いくつかのより良いヒントがあります）。
ה。 API
拡張計画を検討することを忘れないでください。おそらく、クライアントは将来モバイルアプリケーションを必要とするか、たとえばパートナーのウェブサイトを介した商品の販売に同意するでしょう。 いずれにせよ、彼が何かをするつもりであるかどうかを尋ねることを忘れないでください。それは彼自身のAPIの開発を必要とするかもしれません。
コミュニティ開発
時間を節約するために使用できるものを見てみましょう。
比較とレビュー：
- www.readncode.com/blog/the-state-of-ecommerce-in-django（2011年 4月）
- valentinewebsystems.com/en/blog/ecommerce-comparison（2010年 7月、Pythonでの一般的なソリューション-Djangoだけでなく、 komtetからの翻訳があります ）
- www.djangopackages.com/grids/g/ecommerce （定期的に更新/編集）
このトピックに関するブログもあります。
まだHabréにはオスカーに関する記事があります。
一般に、SatchlessとLFSは最もleastりが少ないため、これらは最も適切であると想定できます。 ただし、原則として、最もまともな≠まともなもの：残念ながら、実際にはどちらの場合でも、あなたは自分のフォークで終わる可能性が高く、公式リポジトリからの更新をマージすることは困難です（またはまったく必要ないかもしれませんが-ブランチに影響を与える可能性のあるコミットのセキュリティパッチがあるかどうかを監視する必要があります）。
そして、サッチレスの作者たちは、商品の動的な場の考えにまったく熱心ではないということは、たまたま起こっています。
Satchlessのカテゴリのツリー構造では、すべてが整然としています。 しかし、これは非常に需要があるため、このような決定には非常に期待されています。
LFS（Lightning Fast Shop）に関しては、ツリーカテゴリとEAVの種類があります（多言語ではありません）。 ただし、大規模なプロジェクトでこれを使用することに注意するような方法で実装されています。
ちなみに、Satchlessの作成者はLFSを好まないのです。なぜなら、彼らはLFSをあまりモジュラーではないと考えているからです。
実際には、おそらく最少のハッキングにつながる最速の解決策は、個々の既製のコンポーネントに基づいてストアを書くことです（たとえば、すでにいくつかのバックエンドがあり、新しいものを非常に簡単に書くことができる既製の支払いシステムを利用します）。 最終的に、これらのコンポーネントが個別のアプリケーションの形ではない場合、SatchlessまたはLFSとどれだけ密接に統合されているかを確認でき、あまり強くないことがわかった場合は、そこから抜け出そうとすることができます。
読者には明らかだと思います。上記のすべての問題をすぐに解決する独自のソリューションを作成し、それをインターネットに公開すれば、おそらくすぐに普及するでしょう。