私は、食事計画などの目的でカロリー摂取量と比較するために、物理的属性 (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 番目の例を使用する傾向があります。役立つと思われる提案があればコメントしてください。ありがとうございました!