MySQL の落とし穴をいくつかまとめます-mysql チュートリアル-php.cn

今回は、MySQL を使用する際の注意事項についてまとめてみました。実際の事例を見てみましょう。 Mysql

インストール

はシンプル、高速、そして機能が豊富です。さらに、これはオープンソース運動のベンチマークでもあり、その偉大な成果は、成功する企業がオープンソースコードに基づいて構築できることを示しています。しかし、MySQL を使用したことのある人は皆、モニターに向かって拳を振りました。しかし、毎秒数千行のインターネットデータをエラーなく保存できるテクノロジーを発明することはできません。

この夏を盛り上げるために、オープンソース

リレーショナルデータベース

について不満を言う 8 つの理由をリストします。以下に挙げる理由は MySQL に限定されるものではなく、リレーショナルデータベースに固有のものもあります。リレーショナルデータベースと MySQL を理解しなければ、私たちは常に 1990 年代の考え方に囚われることになります。これらを取り壊してから再構築する必要があります。あるいは、以下のような多くの理由を正当化できるほど長く存在していない、最近人気のあるデータベースに目を向けます。

1. 根深いバグ

どんな大きなソフトウェアパッケージにもバグがあります。しかし、もう少し詳しく調べてみると、Mysql に関連するバグは自己完結型であることがわかります。 NULL は同じように表示されず、外部キー制約は思ったように機能せず、主キーの自動インクリメントさえも失敗するため、突然注意する必要があります。

小さな問題はたくさんあり、常に解決できるわけではないため、リストを作成している人もいます。幸いなことに、MySQL は非常に優れたバグ報告システムを維持しているので、私たちは想像できないことを知ることができ、他の人が同じ試練を経験していることを知ることができます。

2. リレーショナルテーブルの柔軟性の低さ

リレーショナルテーブルは組織化されており、組織化は良好ですが、プログラマは、既にパターンが定義されている列にデータを作成したり、強制的に挿入したりする必要があります。 NoSQL の人気が高まっている理由の 1 つは、NoSQL がプログラマにデータベースの使用を高速化するための十分な柔軟性を提供することです。住所に追加の行が必要な場合は、それを NoSQL ドキュメントに簡単に挿入できます。完全に新しいデータブロックを追加する場合、その内容に関係なく、ドキュメントモデルは、必要なデータ形式に変更することなく、データを変更せずに受け入れることもできます。

すべての郵便番号を整数形式で含むテーブルを作成すると想像してください。このテーブルは非常に効率的で、適用するルールも非常に優れています。突然、誰かがハイフンを使用した 9 桁の郵便番号をアップロードしました。あるいは、カナダの顧客から郵便番号が記載された手紙を受け取るかもしれません。

この時、すべてが混乱していました。上司は、ウェブサイトを数時間以内に復旧して稼働させるように要求しています。ただし、データベースを再構築する時間がありません。プログラマーは何ができるのでしょうか?おそらく、ハッカーを利用してカナダの郵便番号を Base64 デジタル形式から Base10 形式に変更できるのではないでしょうか?それとも、エスケープコードを使用して実際の郵便番号などを示す補助テーブルを設定しますか?知るか？ハッカーはどこにでも存在しており、危険です。しかし、それを理解する時間はありません。

MySQL のアソシエーションルールにより、誰もが正直かつ慎重になりますが、脆弱で欺瞞的になるという問題を回避する必要があります。

3. JOIN

United Queryかつて、データを別々のテーブルに保存することは、コンピューターサイエンスの歴史において大きな革新でした。セパレートテーブルは構造がシンプルなだけでなく、使い方も簡単です。ただし、クエリに join ステートメントを使用する必要があります。

SQL は、一連の結合によって構築された複雑なクエリを通じて、開発者を混乱と絶望の深淵に突き落とします。さらに、ストレージエンジンは、結合ステートメントを最適な方法で効率的に解析する必要もあります。開発者は知恵を絞ってクエリステートメントを作成し、データベースがクエリステートメントを解析する必要があります。

これが、実行速度を重視する多くの開発者がデータサブテーブルを放棄し、代わりに非標準のデータテーブルを使用する理由です。複雑なクエリを避けるために、データエンティティを区別せず、すべてのデータを 1 つの大きなテーブルに保存します。これは非常に高速であり、サーバーのメモリが不足することはありません。

最近のディスク容量は安価です。 8TB ディスクはすでに販売されており、さらに大きなディスクも間もなく登場します。結合を使用するために頭を悩ませる必要はもうありません。

4. ブランチの混乱

はい、確かで十分にサポートされている MySQL フォークは競争と選択肢をもたらす可能性がありますが、混乱や混乱を引き起こす可能性もあります。さらに悪いことに、Monty Widenius によって保守されている MariaDB と呼ばれる MySQL のフォークがあります。彼は MySQL の作成にも携わっています。では、MariaDB は本当に独立しており、サポートに値するのでしょうか?それともMySQLでしょうか？元の MySQL データベースを作成した組織によって実行されているコアコードに固執する必要がありますか?それとも、賢いと思われているクールな脱北者たちに加わるべきでしょうか？

また、互換性に関する情報はどのように入手すればよいですか?一方で、私たちは MariaDB と MySQL が非常に似ていると確信しています。一方で、私たちは違いがあると信じなければなりません。そうでないなら、なぜ誰もがそれについて議論するのでしょうか?おそらく、パフォーマンスとクエリの範囲の点で、どちらの陣営でも同じように機能するのでしょうか?しかし、おそらくそれらは異なるものであるか、将来的には異なるものとなるでしょう。

5. ストレージエンジンの混乱

MySQL は事実上同じデータベースではなく、複数のデータベースで構成されており、それらの詳細のほとんどは均一な表面によって隠されています。当初は MyISAM エンジンがありましたが、高速ではありましたが、一貫性の点で完全ではありませんでした。スピードが必要で、一貫性のない結果を受け入れることができる場合には、それが良い場合もあります。

人々がさらに多くを必要としたとき、完全なトランザクションサポートを備えた InnoDB が登場しました。しかし、これだけでは十分ではありません。現在、ストレージエンジンの選択肢は 20 種類もあり、データベース管理者を夢中にさせるには十分です。もちろん、SQL を書き直すことなく、異なるストレージエンジン間で切り替えることが望ましい場合もありますが、切り替え後は常に混乱が生じます。このテーブルのエンジンとして MyISAM または innoDB を選択する必要がありますか?それとも出力するデータはCSV形式になるのでしょうか？

6. 利益の動機

MySQL はオープンソース製品として成功していますが、それでも、それによって報酬を得ているプロの開発者がたくさんいるビジネスです。ほとんどのユーザーはオープンソースライセンスによってもたらされる最高のエクスペリエンスを引き続き楽しんでいますが、この会社が運営を維持するのに十分な収益を得るのに依然として苦労していることは間違いありません。これにより、「コミュニティエディション」と企業に販売される完全な製品との間で、無料コードの奇妙な分岐が生じます。
お金を払うべきですか？ここでいくら稼いでいますか？コミュニティバージョンで運用するのは公平ですか?エンタープライズ版の追加機能は、私たちをより多くの料金を支払わせるための単なる仕掛けなのでしょうか?これは少なくとも、これが別の一連の質問に答える必要があることを示しています。どのバージョンを選択しますか?どのライセンスに基づいて?どの機能セットを使用すればよいですか?

7. ネイティブ JSON サポートの欠如

MySQL の古さを確認する最良の方法は、MySQL をインストールすることです。そうすれば、それを使用できるようにするためにさらにドライバーを追加する必要があることがわかります。 MySQL は通常、ポート 3306 で通信し、理解できない形式のデータを出力します。コードで MySQL と通信できるようにするには、MySQL の言語を有用なものに変換する別のコード層を追加する必要があります。これらのレイヤーのコードはライブラリとして配布されており、多くの場合、商用ライセンスの購入が必要になります。

最新のデータストレージレイヤーは、多くの場合、JSON で直接通信します。 MySQL と MariaDB は SQL の JSON 部分を解析できるようになりましたが、これは十分とは言えず、ネイティブ JSON インターフェイスはすでに CouchDB、MongoDB、または最新ツールのいずれかで広く使用されています。

8. クローズドソースと独自モジュールの台頭

MySQL はオープンソースであると言いましたか?これは、一部の新しいものを除いて、非オープンソースコードおよび「オープンソースコア」を中心に開発された独自のモジュールです。プログラマーは食べる必要があり、オラクルはその努力の成果をお金と交換する必要があります。これがビジネスの現実の 1 つです。 MySQL を使用して無料の医療を受けられる病院とは異なります。 MySQL を使用して食料を配っている農家とは異なります。

オープンソースの成功は罠になる可能性があるため、MySQL に常に非常に高い水準を維持するよう要求するのは少し不公平です。それは、最初から無料である可能性があるというだけで、常に無料であるという意味ではありません。企業が多くの新機能を必要とする場合、何らかの形で料金を支払わなければなりません。自分でコードを書くよりも、Oracle に支払う方が安い場合があります。場合によっては、商用の非オープンソースコードが意味をなすことがあります。事実がすべてを物語っています。

この記事の事例を読んだ後、あなたはその方法をマスターしたと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。

推奨読書:

Vue で画像カルーセルを作成する

JSは、選択ドロップダウンボックスの最初の要素の値を取得します

Electronのインストールに失敗した場合の対処方法

以上がMySQL の落とし穴をいくつかまとめますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。