小さなMFCがMySQLデータベースに接続し、ODBC経由でインスタンスにログインします
ファイル：n459.com/file/25127180-479633004アクセスパスワード：551685
以下は関係ありません。
- - - - - - - - - - - - - - - - - - - - - -境界線 - - - ----------------------------------------
実は、分散データベースに関する記事を早い段階で書きたかったのです。これが今勉強していることであり、とても興味のあることでもあります。しかし、分散データベースに関しては、多くの関連する技術的な詳細が関係しています。関連する詳細が明確に書かれている場合、12を超える記事がXDに合格しています。したがって、B / B +ツリー、LSMT、CAPなどの技術的な詳細を理解したい場合は、前の記事を読むことができます。今日はNoSQLの概念についてお話します。
noSQLの一般的な意味NoSQLは現在非常に人気があります。私が読んだレジュメの10分の9はnoSQLに精通していますが、noSQLのnoの意味でさえ、noSQLの背後にある詳細を説明できる人はほとんどいません。多くの人が間違いを犯します。これは、そうではないという意味ではなく、だけでなくの省略形でもあります。この頭字語は本当に不正行為であると言わざるを得ません。文字通りそれが何を意味するのか誰も推測できないはずです。そして、それがSQLだけでなく解釈されたとしても、それはまだ少し曇っていて、その要点を理解することはあまり正確ではありません。
SQLの英語の単語は構造化クエリ言語であるため、これは構造化クエリ言語を意味します。特別なプログラミング言語と見なすことができますが、「SQLだけではない」とはどういう意味ですか？それは本当に不可解なので、文字通り理解することはできません。実際のアプリケーションシナリオから理解する必要があります。
SQLアプリケーションのシナリオは、一般的に使用されるOracleやMySQLなどのリレーショナルデータベースであり、リレーショナルデータベースです。データベースを理解するとき、理解するテーブルの構造から始めることがよくあります。データベースに格納されるのはテーブルのシートであり、テーブルはデータの行で構成され、データの各行には固定フィールドがあります。誰もがこの点をよく知っているはずだと思います。データベースを学んだことがなくても、私のような先生に戻ってきたとしても、多少の印象はあるはずです。
しかし、なぜそれがテーブル構造データベースではなくリレーショナルデータベースと呼ばれるのでしょうか。
データベースでは、テーブル構造よりも関係の方が重要だからです。テーブル構造は単なるフォームであり、データベースのコアデザインコンセプトは実際には関係です。これが、データベースの使用方法やSQL言語の詳細について話すのではなく、データベースを学習するときにER図から始める必要がある理由です。この文の意味がわからなくても構いません。まずは脇に置いて、最後にこのトピックに戻りましょう。
問題は、一般的に使用されるSQLデータベースがリレーショナルデータベースであることを知っているので、noSQLで表されるデータベースは何ですか？
noSQLの概念について少なくとも2つのステートメントを見てきました。1つは非リレーショナルデータベースで、もう1つはドキュメントデータベースです。個人的に理解すると、この2つのステートメントは完璧ではないと感じますが、最初のステートメントは情報を提供しないため、2番目のステートメントの方が明らかに優れています。ドキュメントデータベース内のドキュメントは、私たちが通常理解しているドキュメントの意味ではなく、データストレージの構造とコアロジックを指します。
鮮やかな例
ほとんどの技術的概念と同様に、noSQLは比較的あいまいであり、言語で明確に説明することは困難です。そこで私は、誰もがよく知っている活気のある例、つまり全能のXの宝物を引用することにしました。
以下は、Xトレジャーの製品詳細ページの写真です（広告ではなく、自由に選択してください。偶然の一致がある場合は、プロモーション料金をお支払いください）。
誰もがこの写真に精通している必要があります。私たちは通常のオンラインショッピング活動で何度もこの写真を見たに違いありません。少し眩しいようです。上記の内容を抽象化して要約し、スケッチに描きました。次のようになります（少しずさんです）。
つまり、商品詳細ページに表示される内容を大まかに3つに分け、1つは商品画像、もう1つは商品説明、もう1つはユーザーのコメントです。主要なeコマース企業の製品詳細ページのデザインは類似しており、一部の詳細は異なる場合がありますが、全体的なモジュールはそれほど違いはありません。
問題を単純化するために、製品の詳細ページでは、画像情報、テキストの説明、およびユーザーコメントの3つのテーブルを関連付ける必要があると想定しています。実際、この区分はあまり科学的ではありません。たとえば、テキストの説明と製品マップを製品詳細ページのテーブルに保存できます。たとえば、この情報に加えて、在庫、価格、現在のオファー、アクティビティなどの製品販売情報もあります。しかし、これらは私たちの最終的な結論とはほとんど関係がなく、そのように簡単に理解することができます。
上記の分割方法では、itemIdに従って製品の画像、テキスト、コメント情報を検索する必要がありますが、もちろん表面的には問題ありません。しかし実際にはこれには問題があります。問題は、これらのデータが1対1の関係ではなく、1対多の関係であるということです。
たとえば、多くの場合、頭に複数の画像が表示され、テキストに複数の段落が含まれ、同じユーザーが複数のコメントを持っている場合があります。この問題を解決する方法は？
方法を思いつくかもしれませんが、難しいことではありません。itemIdフィールドをimg、text、commentテーブルに追加し、クエリを実行するときにitemIdに関連付けます。
もちろん、そうすることも可能です。あなたがこのプロジェクトを担当するプログラマーであると仮定して、この更新を行い、起動が成功した後、製品は新しい要件をもたらしました。彼女は、テキストの紹介とユーザーのコメントの両方に写真を表示したいと言いました。システムは最初はこのように設計されていませんでしたが、私は気にしません。必要なだけです。
しばらく目を転がし、長い間落ち着いて、それを考えた後、最終的に2つのオプションを考えました。最初のオプションは、現在の画像テーブルにフィールドを追加して、画像を詳細ページの表示またはコメントに使用するかどうかを決定することです。ページ表示、後で追加されるテキストの紹介、およびコメントページの画像はこのテーブルにまだ存在します。2番目の計画は、コメントページと説明ページの写真を保存するための特別なテーブル専用の新しいテーブルを再構築することです。
最初のソリューションの利点は、新しいテーブルを作成する必要がないことです。これにより、テーブルの冗長性が回避されます。すべての要件で新しいテーブルを作成する必要がある場合、その後のメンテナンスに大きな負担がかかることは明らかです。ただし、以前のデータにはソースフィールドがないため、以前のすべてのデータをバッチで変更する必要があるという欠点があります。もちろん、idを使用してこのフィールドなしで区別することもできますが、これは仕様に準拠しておらず、必然的にセキュリティリスクが残ります。
2番目のソリューションの利点は、操作が簡単で、以前のデータを変更する必要がなく、セキュリティリスクが少ないことですが、問題は、一部の詳細ページの写真とトップの写真を共有できるため、新しいリソースを占有する必要があり、使用率が低いことです。それらを別々に保存する場合は、複数のコピーを保存する必要があります。
これらの2つのスキームにはそれぞれ長所と短所があり、どちらも良いように見えますが、落とし穴はすべて共通の短所があることです。つまり、現在のシステムとクエリの複雑さが増します。1つはクエリ時に渡されるフィールドを増やすこと、もう1つは追加のクエリを開始することです。どちらを選択しても、システムはますます複雑になります。その後、ユーザーリクエストが来ると、完全なデータを組み立てるために数十のリンケージリクエストが実行されます。現在、X-Treasureの詳細ページの製品紹介部分の最新バージョンは、テキストなしで常に写真付きで表示されています。おそらく、その背後にあるこの問題が原因である可能性があります。
この例を確認してみましょう。クエリが非常に複雑な理由は、実際にはデータベースのコアコンセプトに関連しています。リレーショナルデータベースに保存されているデータがリレーションシップです。この問題では、製品と画像の関係、製品と説明の関係、製品とレビューの関係、レビューと画像の関係などを照会する必要があります。つまり、最終的に表示されるページは、実際にはこの一連の関係の結果です。各クエリの背後には、関係の分解とマージのプロセスがあるため、非常に複雑になります。
ドキュメントデータベース
eコマースシナリオでのリレーショナルデータベースの問題について説明しました。同じシナリオでのドキュメントデータベースのパフォーマンスを見てみましょう。
リレーショナルデータベースとは異なり、ドキュメントデータベースストレージのコアはドキュメントです。もちろん、ここでのドキュメントは、通常の意味でのドキュメントではなく、jsonまたはxml形式のデータを参照しています。現在のnoSQLデータベースの中で、jsonデータがより一般的に使用されています。また、詳細ページの例を使用して、このデータがnoSQLデータベースにどのように格納されているかを確認します。
{ "ItemID"：123、"itemName"： "iPad Pro"、"topImgs"：["imgs1.path"、 "imgs2.path"]、"desc"：[{"text"： "iPad Pro"、 " img "：“”}、{“ text”：“ 2020 new version”、“ img”：“ imgs1.path”}]、“ comments”：[{“ userName”：“ chengzhi”、“ comment”：“ good product "、" imgs "：[" imgs3.path "、" img4.path "]}] }ご覧のとおり、ドキュメントデータベースでは、複合体をねじ込む前に、複数のクエリと一連の処理が必要になりました。 itemIDを介して1回のクエリでデータを取得できます。
簡単に言えば、リレーショナルデータベースよりもはるかに便利ですが、欠点がないわけではありません。大きな問題の1つは、すべてのデータをドキュメントに直接保存することです。これにより、一方ではデータの冗長性が発生し、他方ではスケーラビリティも制限されます。たとえば、同じ販売者の下にある同様の製品は写真を共有できませんが、複数のコピーを保存する必要があるため、スペースが無駄になります。別の例として、変更するユーザーコメントを格納するすべてのドキュメントを見つける必要があるため（ユーザーコメントが他のシナリオでも使用されていると仮定して）、非常に面倒になる前にユーザーが過去のコメントを変更できるようにサポートしたいとします。とても不便です。
この問題は解決できません。たとえば、ドキュメントに保存されている特定のデータをIDに置き換えることができます。たとえば、特定の画像とコメント情報はコメントに保存されなくなりますが、コメントのIDは保存され、使用時に関連付けられます。 。ドキュメントデータベースの構造により、関連付けのサポートは適切ではなく、接続をシミュレートするためにIDに基づいて手動でクエリを実行する必要があります。これにより、追加のオーバーヘッドも発生します。
もう1つの小さな欠陥は、ドキュメントデータベース内のデータにアクセスするためのパスが長くなったことです。たとえば、製品レビューの2番目の記事で最初の画像を取得したい場合を追加します。item ['comments'] [1] ['imgs'] [0]を書く必要がありますが、リレーショナルデータベースでは、画像はリレーションを介して直接クエリされるため、より便利です。
これらに加えて、noSQLデータベースの開発年数は、MySQLなどのより成熟したリレーショナルデータベースの開発年数よりもはるかに短いため、サポートされる機能は比較的小さいです。
まとめ
例を通して、リレーショナルデータベースとnoSQLデータベースの違いを鮮明に比較しました。記事の冒頭の質問に戻りましょう。データベースの原理とその使用法を直接学習するのではなく、データベースを学習するときにER図から始める必要があるのはなぜですか。
上記の例を理解した後、この問題を見る方がはるかに簡単なはずだと思います。リレーショナルデータベースのコアロジックは、リレーションシップ、使用仕様、さまざまな手法および機能を格納することであるため、基本的にこのコアを中心に開発されています。このレイヤーにたどり着かずにデータベースを使用すると、見当違いになりがちです。これは、考えられない操作の数です。たとえば、誰かがフロントエンドページのコードをデータベースに保存します。たとえば、IDを文字列に連結して、複数を保存します。値など。これはまた、古典的な教科書の内容が無意味ではなく、各章が本来の役割を果たしていることを示しています。したがって、一部の内容が役に立たないと感じた場合、教科書が間違っているとは限らないかもしれませんが、正しく理解していません。