2012-04-24 3 views
1

毎晩設定された時間に属性の値をチェックするスケジュールされたタスクを実行しています。私の計画は、返された値に基づいてフロントエンドを構築することです。IDをグループに割り当てる方法

現時点では、戻ってくるデータ量が多いので、私のデータベースには800個以上の行が戻ってきています。

これらの列のうちの1つは、クエリが実行された日付です。属性のグループごとに(つまり、毎晩スケジュールされたタスクが実行されるため)、このdateTimeの値は同じになるため、これは冗長です。

この冗長な/繰り返しの日付をデータベースから削除するにはどうすればよいですか?助けのための

Id -- Name -- AttributeIMeasure -- dateRan 

ありがとう:私はの見出しをcolmnしている時点では

+0

クエリから返されたデータはどうしていますか?それをデータベースに戻して保管していますか、それをファイルに書き込んだり、それと似たようなことをしていますか? – dasblinkenlight

+0

クエリから返されたデータは、NameおよびAttributeIMeasureに格納されたデータを構成します。だから私はあるデータベースから別のデータベースにコピーしています(コピー元のデータベースは動的で時間が経つと追跡したいと思っています)。 –

答えて

3

私は主キー列、Id、およびRunDateコラムで、RunInformation、別のテーブルを作成するために誘惑されるだろう:

Id -- RunDate 

あなたはその後、参照してあなたのテーブルからdateRan列を置き換えることができますRunInformationテーブルに追加します。これにより、将来必要に応じて実行に関する追加情報を保存することができます。

+0

私は見ましたが、これは格納された冗長データを減らさないでしょうか?特定の日に、クエリの実行ごとにNameとAttributeIMeasureを持つ行のリストが返されるため、返されたすべての行に対してRunDateは同じになります。 :) –

+0

ああ私はあなたが今何を意味するかを見ます。これにより、冗長性が軽減されます。 RunInformationテーブルにどのような参照を追加する必要がありますか? –

+1

'RunInformationId'を既存のテーブルの外部キーとして追加する必要があります。 – weenoid

1

この冗長性は削除しません。

特定のの場合は、のグループを更新することはできませんか?
- 何らかのエラーが発生しましたか?
- 今後の要件の変更?

また、冗長性の本当の側面は何ですか?実際に何が問題解決しようとしていますか?


あなたがこれを行うには本当に必要を行う場合は、単にマッピングの方法は、グループに属性を必要とします。

attribute_groupsテーブル(IDとdateRanフィールドは最低限)を作成し、元のテーブルにattributeGroupIDフィールドを追加します。


しかし、私はまだ追加のスキーマの複雑性の増加は、DateRan値を取得するために必要なジョインをどのように見ると、制約が増加していないが、この場合はそれだけの価値があります。

+0

お返事ありがとうございます。データベースに保存した値に基づいてフロントエンドを構築したいと考えています。おそらく次の数年間は夜間に走り、夜は〜800の結果を返します。このデータのすべては、dateTimeを除いて必要です。私はこの性質の大規模なプログラミングの経験はほとんどありませんが、すべてのデータが格納されている状態で、可能であればすべてのデータから1つの列を削除することが重要であると仮定していました。 –

+1

このようなストレージについて心配しないようにします。このような小規模なスペースと効率については、おそらくそれほど心配する価値はありません。何百万ものレコードにスケールアップしない限り、スペースの違いはごくわずかです。 – Sorpigal

+0

アドバイスをありがとう、それは非常に知っておくと便利です:)。 –

関連する問題