かなり粗雑なアイデアがあり、それに基づいてインターネット製品を構築する必要があるとします。 どこから始められますか？ または、アイデアが生の場合、実装に関して何もすべきではありませんか？ ただし、これは常に可能とは限りません。 むしろ、現在の要件が最終的なものか明日すべてが最も重要な方法で変更されるのかを開発者が理解することは困難です。 そして、私たちは、フレームワークが決定されたことをしっかりと確信し、機能し始めました。 すべてがうまくいけば、結果は良好になり、プロジェクトコードは非常に美しくなります（プログラマーのスキルに正確さを持って）。 しかし、すべてがうまくいくわけではありません。 そして、一般的な場合、プロジェクトは次のように移動します。
- アイデアに基づいて、ベースが設計されます-後で最初の近似になることが判明したためです。 各情報エンティティには個別のテーブルがあります。 各特性には独自のフィールドがあります。
- プロジェクトの一部は、受け取ったベースに基づいて構築されました。 ロジックが実装され、レイアウトが拡張されます。
- 顧客（または「内部顧客」）との協議。 ここでは、すべてを変更する必要があることがわかります。 2日前に持っていた情報は古くなっていたため、私たちが疑わない機能さえ発見しました。 この状況は非常に一般的です、なぜなら 完全なプロセス図を作成するのに苦労する人はほとんどいません。
- データベーススキーマの一部を変更します-最も単純なケースでは、フィールドを追加/削除する必要があります。 これに続いて、すべてのSQLクエリを変更します。 この場合の3番目の必要な手順は、新しい条件でのテストです。
そして、ポイント2からサイクルが繰り返されます。 あまりにも多くのケースがあり、さらに非常に骨の折れるケースがあると思います。 私が見たものに基づいて、自分自身を見て、ワークショップで同僚の経験を研究すると、ある時点で開発者が疲れて、システムの再設計が最適でないソリューションにつながることは明らかです。
一方で、プロセスの明確な（プログラマーにとって）絵の欠如は悪いことであり、そのような状況では良い結果を待つ必要はないように思われます。 一方、これは完全に重要な状況であり、顧客の特性だけでなく、客観的な理由によっても説明できます。 実際、少なくともある程度の既製の活気のある製品があり、ロジックが実装され、関係が構築されているため、事前に考えられなかった、または考えられなかったこれらの質問がすぐにポップアップします。
私自身は、実装の重要な詳細を十分に理解するまで、段階で人件費を最小限に抑えることができる優れた方法を見つけました。 そして、何らかの動作モデルを取得した後にのみ、それらを明確にすることができます。 このアプローチの本質は、すべての情報エンティティを別々のテーブルに格納することですが、フィールドを分離することはありません。 JSON配列の形式。 これにより、任意の大きな複雑さのオブジェクトを保存できます。
このアプローチにより、フィールドを変更/追加するときにデータベースにアクセスせず、新しい条件でクエリを変更およびデバッグする時間を無駄にすることなく、純粋なロジックと検証を変更するだけで済みます。 将来、JSONでパックされたデータの保存から正規化された構造に移行する場合、リクエストのみをほとんど変更する必要があり、ロジックとチェックは変更されません。
NoSQLストレージから通常のテーブルに切り替える必要があるのはなぜですか？ 私にとって、この質問は簡単に解決できます。MongoDBの専門家などとは言えませんが、商業開発には実績のあるツールを使用することをお勧めします。 ただし、選択肢があり、プロジェクトにアナリストのスタッフがいない場合（データベースにSELECT *を書き込む）、サードパーティのサービスはデータベースを使用しませんが、すべてのストレージをNoSQLトラックに転送できます。
したがって、初心者向けにJSON文字列のスタイルで構造全体を設計することで、デバッグにかかる時間を節約し、より早く完成した結果を得ることができます。これにより、十分に完全で合理的なアーキテクチャを構築するために必要なすべての問題を解決できます。
ここに私が言わなければならないことがあります。