3

彼女が話す言語をチェックしてデータベースに保存するようにユーザーに提供するとします。重要な注意点として、検索用に別の検索エンジンがあるため、これらの値をデータベースで検索することはありません。さて、これらの値を保存する明白な方法は、次のようなテーブルを作成することです。

UserLanguages
(
 UserID nvarchar(50),
 LookupLanguageID int
)

ただし、サイトの負荷が高くなり、可能な限りオーバーヘッドを排除するように努めているため、UIで結果を表示するときにメインメンバーテーブルとの結合を回避するために、ユーザーの言語をメインテーブルに保存して保持することを考えていました。 「12,34,65」のようにカンマ区切り

繰り返しますが、私はそれらを検索しないので、その列で全文索引を作成する必要はありません。

このソリューションに問題はありませんが、何か見落としていますか？

ありがとう、アンドレイ

4

9 に答える 9

16

しないでください。

  • あなたは今それらを検索しません
  • データはこの1つの状況以外には役に立たない
  • データの整合性がない（例：FKがない）
  • 表示するには、「英語、ドイツ語」などに変更する必要があります
  • "xを話すすべてのユーザーを教えてください"=FAIL
  • リストは実際にはプレゼンテーションの問題です

しかし、それはあなたのシステムであり、後で避けられない「ヘルプ」の質問に答えることを楽しみにしています...

于 2009-09-28T19:26:25.097 に答える
12

今は何も見逃していないかもしれませんが、要件が変更されたときに、その決定を後悔する可能性があります。最初の本能が示唆するように正規化して保存する必要があります。それが正しいアプローチです。

あなたが提案しているのは、古典的な時期尚早の最適化です。その参加がボトルネックになるかどうかはまだわからないため、実際にパフォーマンスの向上を購入しているかどうかはわかりません。物事をプロファイリングできるようになるまで待ってください。そうすれば、その部分を最適化する必要があるかどうかがわかります。

もしそうなら、私はマテリアライズドビュー、または記録簿とは見なされないキャッシュへの正規化されたデータを使用して回答を事前に計算する他のアプローチを検討します。

より一般的には、必要に応じて、提案した方法で設計を損なうことなく実行できる最適化が多数あります。

于 2009-09-28T19:27:55.937 に答える
11

このタイプのストレージは、ほとんどの場合、私を悩ませるために戻ってきました。一つには、あなたは最初の正規形でさえありません。別の人のために、何人かのマネージャーまたは他の人が間違いなく戻ってきて言うでしょう..「ねえ、これを保存したので、私にレポートを書いてくれませんか...」

正規化された設計を使用することをお勧めします。別のテーブルに入れてください。

于 2009-09-28T19:21:22.550 に答える
5

問題：

  1. あなたは参加能力を失います（明らかに）。
  2. 各ページのロード/ポストバックでリストを再解析する必要があります。その結果、コードクライアント側が増えます。
  3. データベースの整合性を維持しようとするすべてのふりを失います。後で言語を削除することにした場合を想像してみてください...すべてのユーザープロファイルを修正するためのSQLは何になりますか？
  4. さまざまなプロファイルオプションがDBのルックアップテーブルに格納されていると仮定すると、プロファイルページごとに「30クエリ」を実行する必要があります。そうでない場合は、小さな変更ごとにコードをデプロイする必要があります。悪い、非常に悪い。
  5. 「起こらない」何かに基づいて設計を決定することは、失敗の絶対的なレシピです。確かに、ビジネスマンは決してそれをしないと言いました...彼らが絶対にそれをしなければならない理由を考えるまで。今日。これは、コーディングが終了するとすぐに表示されます。
  6. コメントで述べたように、使用率の低いページに対する30のクエリは何もありません。汗を流さないでください。また、それが必要であることが確実にわかっている場合を除いて、絶対に最適化しないでください。プロフィールページに対してSOが行うクエリの数を推測しますか？
于 2009-09-28T20:14:27.927 に答える
4

私は通常、あなたが説明した解決策には近づきません。そのような方法でリレーショナルデータを保存するときに問題が発生します。

別の解決策として：たとえば、1つのビットマスクされた整数として格納できます。0-選択なし1-英語2-スペイン語4-ドイツ語8-フランス語16-ロシア語-など2の累乗

したがって、誰かが英語とロシア語を選択した場合、値は17になり、ビット演算子を使用して値を簡単にクエリできます。

于 2009-09-28T19:27:15.220 に答える
4

時期尚早の最適化はすべての悪の根源です。

編集： どうやら私の観察の文脈は、一部の人によって誤解されているようです-したがって、反対票。だから私は明確にします。

モデルを非正規化して、物事を簡単にしたり、「パフォーマンスを向上させたり」（OPの場合のように、ビジネス情報を表す連結列を作成するなど）は、私が「時期尚早の最適化」と呼んでいます。

特定の問題ドメインに必要なパフォーマンスを得る他の方法がない極端なエッジケースがあるかもしれませんが、これが事実であると想定することはめったにありません。一般に、このような時期尚早な最適化は、元に戻すのが難しいため、長期的な悲しみを引き起こします。データモデルを本番環境に移行した後、最初に展開したときよりも多くの労力を要します。

データベースを設計するとき、開発者（およびDBA）は、正規化などの標準的な手法を適用して、データモデルが収集および管理されるビジネス情報を確実に表現するようにする必要があります。データの正規化を適切に使用することが「最適化」であるとは思いません。これは必要な方法です。私の意見では、データモデラーは、（少なくとも）第3正規形（3NF）に再構築できるモデルを常に監視する必要があります。

于 2009-09-28T19:34:01.703 に答える
2

それらに対してクエリを実行していない場合は、最初の計画のような形式でそれらを保存することにより、何も失うことはありません。もしそうなら、それらをコンマ区切り形式で保存すると、あなたを悩ませることになります。特に、それらを元に戻すために必要な作業を考慮すると、速度の節約が重要になるとは思えません。

于 2009-09-28T19:53:29.460 に答える
1

ルックアップテーブルの結合をいくつか追加することについて、非常に心配しているようです。私の経験では、実際にHTML応答を送信し、ブラウザーにそれをレンダリングさせるのにかかる時間は、いくつかの余分なテーブル結合をはるかに超えています。特に、主キーと外部キーにインデックスを使用している場合（必要に応じて）。まるで、数日間のクロスカントリー旅行を計画していて、10分間のバスルームの停車が1回増えるのではないかと心配しているようなものです。

長期的な柔軟性とデータの整合性の欠如は、このような小さな最適化には価値がありません（これは必要ではないか、目立たない場合もあります）。

于 2009-09-28T20:39:06.700 に答える
0

Nooooooooooooooooo !!!!!!!!

上記のいくつかの投稿で非常によく述べられているように。

この議論に反対の見方をしたい場合は、ワードプレスを見てください。テーブルは区切られたデータでいっぱいになっていて、それは素晴らしい、シンプルなプラットフォームです。

于 2009-09-28T20:18:04.930 に答える