0

私は、食事計画などの目的でカロリー摂取量と比較するために、物理的属性 (ht、体重、体水分、体脂肪など) を経時的に追跡できるローカルホスト用のアプリケーションを開発しようとしています。これが私が持っているものです。たった今：

DB surname
 TBL home
  memberID (tiny int, 1, auto increment, primary key)
  name (varchar, 30)
  gender (char, 1) ->value should be m or f, but this isn't defined anywhere
  birthdate (datetime)

経時的に物理データを保存するために、日付またはのすべてのエントリを検索できるように、各列に通常の単一列インデックスを持つ 3 列の主キー (日付、人、測定の種類) を持つテーブルを用意することを検討しました。人 OR 測定タイプ。このような：

DB surname
 TBL stats (or something to that effect)
  date (datetime, PK1, index)
  memberFK (tiny int, 1, PK2, index)
  type (varchar, 3, PK3, index) -> possible values should be ht | wt | fat | wat maybe others will also become necessary
  value (decimal, 4/1) -> store all values in nnn.n format in a particular system (ie metric) and do any conversions, add units, etc when the data is called

これはまだ多くの過剰な冗長性を生み出しているように見えるので、次のように、各ユーザーの測定値を独自のデータベースのテーブルに保存することを考えました。

DB user1
 TBL stats
  date (datetime, PK1, index)
  type (varchar, 3, PK2, index)
  value (decimal, 4/1)

これは、外部キー (およびテーブル全体) から列を削除することで少しきれいになるようですが、このテーブルとユーザー固有ではない他の栄養関連のテーブルとの間で外部キーを使用することもできなくなります。一方で、一般的なデータとユーザー固有のデータがある他の家庭のトピックのアプリケーションを開発する予定なので、そのようなデータベース間でデータを使用する良い方法があれば、これが最善の方法かもしれません.

したがって、これらのどちらも私にはまったく正しくないように思えますが、それらをより良くする方法について途方に暮れています. データの整合性を維持する方法を見つけられる場合は、2 番目の例を使用する傾向があります。役立つと思われる提案があればコメントしてください。ありがとうございました！

4

2 に答える 2

2

これが私がそれを行う方法です

DB healthstats
    TABLE user
        memberID (int*, auto increment, unsigned zerofill, primary key)
        name (varchar, 50)
        gender (char, 1) ->value should be m or f, but this isn't defined anywhere
        birthdate (datetime)

    TABLE reading
        readingID (int*, auto increment, unsigned zerofill, primary key)
        memberID (int*, FK: TABLE user)
        date (datetime)

    TABLE stat
        statID (int*, auto increment, unsigned zerofill, primary key)
        readingID (int*, FK: TABLE reading)
        type (varchar, 3)*
        value (decimal 4.1)*

*これらのデータ型は、何が理にかなっているのかに基づいてあなた次第です。主キーと外部キーが一致していることを確認してください。

Astatは測定値 (例: 身長、体重、体脂肪など) です。Aは、同時に行われたreading1 つまたは複数の測​​定値として定義されます。stat

これはすべて同じデータベース内にあり、3 つのテーブルが含まれていることに注意してください。

于 2012-06-26T21:39:54.337 に答える
0

同じ構造を持つ複数のテーブルを持つことは、正規の形式で複数のそのようなテーブルからデータにアクセスできなくなるため、ほとんどの場合、悪い考えです。夏と冬の平均体重差が必要だとすると、ユーザーごとに分割すると、すべてのテーブルを反復処理する必要があります。

あなたのアプローチのどこに「過剰な冗長性」があるのか​​ わかりません。しかし、enum 列の値ではなく、さまざまなパラメーターを列として持つテーブルの方が快適かもしれません。つまり、列 ht、wt、fat、wat など、必要な列を導入します。こうすることで、これらすべての値に対して 1 つの数値型に制限されることはなく、まったく関係のない単位の値を同じ列に格納することもありません。欠損値には引き続き使用できるNULLため、強制したいポリシーでない場合でも、常にすべての値を指定する必要はありません。セット全体で日付と人物が 1 回しか表示されないため、通常、1 人の人物に対して複数の読み取りを行う場合にのみ意味があります。

于 2012-06-26T21:47:15.940 に答える