辞書WebサイトにMySQLを使用するのはなぜ悪い考えですか？

辞書のエントリ（通常は単一の単語）とその意味を別の言語で保存するデータベースを設計および設定する予定です。したがって、たとえば、テーブル用語集にはエントリと定義が必要であり、各テーブルレコードには、格納されているレコードのIDへの参照がありますTag（各エントリにはタグまたはカテゴリが必要です）。

私のデータは構造を持っているので、SQLデータベース（MySQLなど）を使用することは悪い考えではありません。しかし、人々はMongoDBの方がパフォーマンスがはるかに優れていると言います。

クライアント側では、アプリケーションは、バックエンドが提供するREST APIを使用するオートコンプリートを備えた検索ボックスを提供できる必要があります。このようなシナリオでMySQLを使用するのは安全ですか？または、これに他のソリューションのMongoDBまたはElasticSearchを使用する必要がありますか？このようにして、数十万件のレコードが保存およびアクセスされることになっています。

なぜそれが悪い考えなのか、あなたには言えません。ただし、リレーショナルデータベースが優れたアイデアである理由はたくさんあります。

1. 誰もが定義のために辞書を参照するわけではないことに注意してください。多くの場合、辞書を使用して正しいスペルを見つけます。これは、干し草の山で針を見つけるだけでなく、ユーザーが説明したものに似た針を干し草の山で検索していることを意味します（イディオムを使用する場合）。

   主キー検索を行うだけではありません。キーワード検索を行うことになります

2. 単語は、意味またはスペル（read、read、redおよびreed）のいずれかで関連付けることができます

   「関連する」という言葉が表示されるたびに、「リレーショナルデータベース」を考えてください

3. 速度が必要な場合は、破損したリレーショナルデータモデルではなく、リレーショナルデータベースの上にキャッシュする必要があります。

4. 適切に正規化されたデータベースは、ふるいにかけるビットが単純に少ないため、主キーの検索と検索を高速化します。

5. 正規化されたデータベースは遅いと言う人は、これが当てはまるケースの0.1％に言及しています。他の99.9％のケースでは、真に正規化されたデータベースを実際に使用してパフォーマンスを実際に確認したことがないため、無視してください。正規化されたデータベースを使用しました。大好きです。戻りたくない。そして、私はデータベースの男ではありません。私はC＃/ JavaScript / HTML / Rubyの男です。

6. 言葉には起源があります。実際、同じ言語の多くの単語は同じ起源を持つことができ、これは異なる言語の別の単語です。たとえば、履歴書（今後7年間、絶え間ない電話や電子メールを受け取るために採用担当者のWebサイトにアップロードするもの）はフランス語です。

7. また、辞書では、どのような単語（名詞、動詞、形容詞ect）であるかも定義します。これは単なるテキストではなく、「名詞」にも意味があります。さらに、リレーショナルデータベースを使用すると、「英語のすべての名詞を教えて」などと言うことができます。正規化されたデータベースは外部キーを利用し、外部キーはインデックスを持っている（または持つべき）ので、ルックアップは簡単です。

8. 単語の発音を考えてください。特に英語では、多くの単語の発音が同じです（上記の私の例であるreadとreed、またはreadとredを参照）。

   単語の発音自体は、別の単語です。リレーショナルデータベースを使用すると、発音に外部キーを使用できます。その情報は、リレーショナルデータベースでは複製されません。非SQLデータベースでは狂ったように複製されます。

9. それでは、単語の複数形と単数形について話しましょう。:)「ボート」と「ボート」を考えてください。または、単語が「単数形」または「複数形」であるという事実。

10. ああ！そして今、過去時制、現在時制、未来時制、現在分詞について話しましょう（正直に言うと、「現在分詞」というくだらないものが何なのかわかりません。英語か何か）。

    「実行」を検索すると、他の時制が表示されます：実行、実行、実行

    実際、「時制」は別の関係そのものです。

11. 英語はこれをあまり行いませんが、性別は言葉を定義する別のことです。スペイン語のような言語には、名詞の主題が男性か女性かを定義する接尾辞があります。文の空白を埋める必要がある場合、多くの言語では性別が非常に重要です。

    言語の慣習に依存して性別を判断できるとは限らないため（スペイン語では、「o」で終わる単語は男性/男性ですが、すべての単語に当てはまるわけではありません）、男性または女性の識別値が必要です。これは、正規化されたデータベースが数百万件のレコードでも適切に処理するもう1つの関係です。

すべてのねじれたルールと単語間の関係、さらには異なる言語でさえ、このデータストアをno-SQLソリューションが提供するような「ドキュメントストア」と考えるのは困難です。単語とそのコンポーネントの間には非常に多くの非常に多様な関係があるため、リレーショナルデータベースが唯一の賢明なソリューションです。

キー値ストア（より貧弱なプログラミングモデルを提供します）を使用して、より多くの構造が必要な場合（たとえば、第3言語を追加する場合）、または結合を含むより複雑なクエリを実行する必要がある場合、キーの再編成、データの非正規化、および/またはすべてのデータをループして必要なものを見つけるために多くの時間を費やします。

リレーショナルデータベースから始める場合は、アプリケーションの設計、コードを検討し、キー値形式に靴磨きをかけるのではなく、アプリケーションの自然なデータモデルに集中して試してみることができます。

アプリケーションが落ち着いたら、さまざまなオプションを測定することにより、パフォーマンスに取り組むことができます。テクノロジーを切り替える必要がある前に、SQLで実行するパフォーマンストリックがかなりあります。アプリケーションについて多くのことを学び、リレーショナルがあなたを傷つけているかどうか、Key-Valueがデータモデルで機能するかどうかを判断する上ではるかに優れた立場になります。

Key-Valueがアプリケーションに必要なものであることが判明した場合、リレーショナルモデルへの多大な投資を無駄にせずに切り替えることができますが、逆に、Key-Valueモデルがリレーショナルモデルでは自明です。

常に変化する要件に直面して、ドメインとユーザーの詳細を把握しながら、アプリケーションを設計、作成、実行するためのアクセラレータとしてリレーショナルデータベースを検討してください。

何百万人ものユーザーがいる場合、たとえ最初からKey-Valueを選択したとしても、ほぼ間違いなくデザインをリファクタリングする必要があります。

これほど小さいデータベースの場合、おそらくパフォーマンスに大きな違いはありません。おそらく、与えられたエントリの書き込みよりもはるかに多くの読み取りがあるはずなので、標準のRDBMSはここではひどい考えではありません。これはパフォーマンスが主な要因ではないようです。アプリケーション層でのキャッシュは、このような懸念も軽減します。

もう1つの考慮事項は、複製と復元力です。リレーショナルデータベースは、単一のインスタンスを中心に設計される傾向があります。CAP定理を読んで、最も重要なことを検討する必要があります。

これらのNoSQLデータベースは、最初は常に良いアイデアのように聞こえますが、エッジケース（たとえば、キーワードが値（またはその一部）で検索する必要がある場合）の処理を開始すると、問題が発生することが保証されます。

最初はリレーショナルデータベースを使用し、後で非正規化する方が安全です。MySQLはこの種の目的に最適です（テキストベースの検索を使用した単純なリレーショナルデータベース）。この種のデータに苦労するユースケースはあまりありません。インデックスが正しく設定されていることを確認してください。NoSQLデータベースと同等のレベル（またはテキスト検索を行う場合）で実行されることがわかり、アプリロジックを変更せずに柔軟に変更できます。具体的なデータ構造にバインドされています。

データの最も一般的な使用法を見つけた場合（およびパフォーマンスのニーズを満たしていないことがわかった場合）、ロード（および取得）可能なセット形式に出力することにより、データの非正規化に進むことができますNoSQLスキーマ。