0

各フィールドに 5 つの固定回答がある 14 のフィールドがあるフォームのデータベースを構築する方法がわかりません。レコード数は通常、実行時に 30 ~ 200 レコードの間で変動する場合があります。ただし、100 を超えるレコードは一般的ではありません。時折 400 レコード テーブルを取得することがあります。

多くの場合、エントリの特定の組み合わせが繰り返されるか、一連のレコードに共通の値がほとんどありますが、これらのどれがレコード挿入間で変化するかを予測することはできません。


大量の繰り返しは避けたいと思いますが、可能であれば検索効率を十分に維持したいと考えています。以下は、私が提案したスキーマです。

スキーマ 1: 14 フィールドの大きなテーブル 1 つ。小さなデータセット (<30) ではおそらく問題ありませんが、200 ですか? アンドロイド?


スキーマ 2:正規化の試み: 外部キーを持つ 14 - 2 テーブルに分割します。試行錯誤以外に、最適な数を決定する方法がわからない。


スキーマ 3:もう少し複雑ですが、理解するのは難しくありません。

2テーブル。表 1 には 14 のフィールドがあり、主キーは 14 のエントリの特定の組み合わせに対応しています。次に、表 2 は外部キーを使用して、表 1 の組み合わせに対応する FK に従ってレコードをログに記録します。新しい組み合わせは、実行時に表示されるときに表 1 に入力されます。

次に、マップを使用して、入力されたレコードが既存の組み合わせに対応するかどうかを確認します (これもその場で生成されます)。マップキーは、フィールド内の個別の値の合計です* - マップキーを生成するより良い方法はありますか? 一意のキーを安価に生成する方法は考えられません。次に、条件を使用して、同じような合計を持つコンボを区別する必要があります (if組み合わせを一致させるには 13 秒ですよね?)

※各欄の各状態は数値に対応しています。

このスキーマ (3) は、規定の範囲を超えてスケ​​ーリングする可能性が高いですか、それとも悪い考え/過剰/完全に不適切ですか?


これを完全に行うためのより良い方法はありますか?

RDBMS を使用するのはこれが初めてであり、ご協力いただけると大変助かります。

編集: また、これは合計 32 のフィールドを持つ大規模なデータベースの一部であり、いくつかの個別のフィールドといくつかの文字列であることに言及するのを忘れていました。

4

1 に答える 1

1

私の直感では、数千または数万のレコードに到達するまでは、レコード数が多いことを心配する必要はありません。実際、400 レコードのデータベースを 400 行のテキスト ファイルと考えることができます。Android は、1 万行から 10 万行の巨大な xml/json ファイルを簡単に解析できます。Android では、30 から 400 のレコードが完全に許容されるはずです。

私がスキーマ 3 を正しく理解していれば、5^14 の事前構成された状態を保持し、メイン テーブルのエントリが選択可能性テーブルの特定の状態構成を参照する予定ですか? 5^14 = 6103515625 なので、これはやり過ぎのように思えます (もちろん、これは最悪のケースです)。重複した状態が多数ある場合は、スキーマ 3 を選択することで [おそらく] 顕著なメモリ使用量の削減が得られますが、これは不必要で初期の最適化であるように思えます。

一般に、最初に適切に機能するシステムを計画し、次に必要に応じてリファクタリングします。最初から最も網羅的で精巧なスキームを作成しようとしないでください (データベースまたはコーディングは問題ではありません)。

おそらく、最も単純なスキーマであるスキーマ 1を使用するのが最も効率的です。レコード数が問題になるところまで来たら、後でスキーマ 3のようなものにリファクタリングします。

または、これらのビットをパックする方法を見つけてください。5 つのオプション、14 の状態、2^3 は 8 つの状態、3 * 14 = 42 ビットを保持します。すべての選択が入ってくるとツリーを生成し、それを 3 ビット ステージでトラバースすることができます。もちろん、ツリーはメモリに収まらないため、分割してシリアル化する方法を見つける必要があります..

于 2013-04-03T13:28:58.953 に答える