0

私はデータベースに不慣れですが、この質問は、データベースがどれほど賢いと期待できるかと関係があります。ここで「データベース」とは、MySQLまたはH2の「ようなもの」を意味します（これら2つが類似しているかどうかは実際にはわかりませんが、人気があるというだけです）。私は実際にScalaQueryを使用しているので、基盤となるデータベースから抽象化します。

タイプ（String、Int）のエントリを含み、Stringエントリに多くの冗長性があるテーブルがあるとします。したがって、私のテーブルは次のようになります。

（アダム、18）（アダム、24）（アダム、34）...続き...（アダム、3492）（ベサニー、4）（ベサニー、45）...続き...（ベサニー、2842）

このテーブルをH2と一緒に保存すると、「Adam」と「Bethany」が何度も繰り返され、ルックアップテーブルを指す列挙に置き換えることができるほど賢くなりますか？それとも、大量のストレージを浪費するのでしょうか。

関連：H2が文字列に関してこの点で賢い場合、それはダブルスでも同じように賢いですか？私のおそらく脳死した初期のテーブルでは、たまたま繰り返しダブルフィールドがたくさんあります。

ありがとう！

4

5 に答える 5

6

データベースエンジンは、データの冗長性を認識して修正するようには構築されていません。それがデザイナー/開発者の仕事です。

于 2011-08-23T23:57:59.207 に答える
2

データベースは情報を保存するように設計されています。（Adam、44）と（Adam、55）を圧縮できるかどうかをデータベースが知る方法はありません。データベースがあなたの提案したようなことを行おうとすると、さまざまなパフォーマンスや論理につながる可能性があるため、私は石化するでしょう。問題。

反対に、データベースはストレージを最小化しておらず、インデックスやキーなどの冗長な情報や、DBに必要なその他の内部追加情報を追加しています。

DBは、情報をスペース効率よく保存するのではなく、情報を高速に取得するように構築されています。複雑さに関しては、データベースはむしろストレージスペースを増やし、クエリのパフォーマンスを低下させます。

于 2011-08-24T00:06:40.040 に答える
1

ページを圧縮するストレージシステムがいくつかあるので、質問は有効です。MySQLについて話すことはできませんが、H2に似ていると思います。H2はこの点であまり賢くありません。H2はデータを圧縮しますが、次の場合に限ります。

  • LOB圧縮（有効な場合）。
  • 以下は、閉じたデータベースのストレージサイズには影響しません。現在、 LZFを使用して書き込む場合、H2はUNDOログを圧縮します。したがって、ページでデータを繰り返すと、書き込みパフォーマンスがわずかに向上します（ただし、チェックポイント後のみ）。ただし、これは将来変更される可能性があります。

また、H2はUTF-8と同様のコードを使用してテキストを格納しますが、この圧縮とは呼びません。

于 2011-08-24T04:19:12.547 に答える
0

データベースエンジンで実行できるデータ圧縮について話しているので、心配する必要はありません。または、データの正規化について話している。次に、データベース設計について読む必要があります。

データベースはデータを保存することを目的としているため、少しの冗長性について心配する必要はありません。数百万行とギガバイトのデータを処理する場合は、オプションの検討を開始できます。ただし、そのレベルまでは、パフォーマンスに問題はありません。

于 2011-08-24T09:09:52.137 に答える
0

連続ストレージに基づくMySQLおよびその他のSQL製品は、この種のことではまったく賢くありません。

一方が他方を参照する2つの論理セット（つまり、外部キー）について考えてみます。考えられる実装の1つは、両方のセットに共通の値を1回だけ物理的に格納し、両方のテーブルに値へのポインターを格納することです（C＃などの3GLプログラミング言語の参照型変数を考えてみてください）。ただし、ほとんどのSQL製品は、値を両方のテーブルに物理的に格納します。ポインタが必要な場合は、エンドユーザーが自分でポインタを実装する必要があります。通常は、自動インクリメント整数の「代理」キーを使用します。これは、悲しいことに論理モデルに公開されます。

于 2011-08-24T09:04:20.130 に答える