0

「メモ」とメモが適用される日付を保存する必要があるコーディングの問題があります。のことを考える：

注1こんにちは、今日、クライアント氏はこれらの予定を手配するために電話をかけました。2009年8月30日、2009年8月31日、2009年5月9日

注2通常通りの営業。2009年8月30日

注3レストランは休業です。2009年6月9日

効率的に取得するためにインデックスを維持しながら、次のデータをデータベースに保存する必要があります。つまり、クライアントアプリケーションは日付を選択し、その日付に関連するすべてのメモを排他的または部分的に取得する必要があります。

私は数人の同僚や友人と話し合い、このデザインにたどり着きました。すべての情報を1つのテーブルに保存できるようにしたいので、デザインがエレガントな場合はそれ以上に保存できるようにしたいと思います。

> Date Bitmap | Month | Year | Note
> 101..         9       2009   Blah Blah     // applies to 1st and 3rd
> 0001...       10      2009   Blah2         // applies to the 4th
> 100           9       2009   Blah23

ユーザーが複数の日付ピッカーから次の日付を選択すると、9月1日にBlahBlahとBlah23が取得されます。単一の日時オブジェクトは、メモを繰り返すか、外部キーを使用して別のテーブルを強制的に作成します。

メモが適用される月の曜日を最初の列に格納できるという意味で。ビットマップでは、物事は非常に効率的である可能性があります。他の方法（Note-IDを持つリンクされたテーブル、またはIDを持つすべての日を持つテーブル）はすべて、メモフィールドまたは繰り返される日付のいずれかの醜い重複をもたらしました。また、区切り文字付きの日付のセットを含むテキストフィールドと、検索時に解析する醜いコードについても考えたくありません。

お分かりのように、私にはこのプロジェクトに時間を割く余裕があります。

しかし、クライアントアプリケーションのRETRIEVEは、特定の日付セットのすべてのメモをどのように言うことができますか？MSSQLにビット演算はありますか？したがって、すべての行を取得できます。たとえば、そのバイナリフィールドの5番目と7番目のビットに「1」がありますか？

範囲や何か、または種類にない散発的な日付がある可能性があるため、BETWEENを使用できません。1から31までの任意の数値を表すことができるデータ型を考えてみてください。それが私がビットマップについて考えた方法です。

また、実際の日付（実際のテキスト）がルーチンによって入力されるテキストフィールドを追加することもできます。しかし、残りの部分については、このアプリケーションがメインインターフェイスになり、ユーザーが醜いテーブルを見る必要があることはめったにありません。

私は過剰設計ですか、それとも私を助けてくれますか？

返信ありがとうございます。

レオ

4

3 に答える 3

2

はい、あなたは過剰設計です。

単一の日時列を作成し、インデックスを作成するだけです。日時を分割する場合は、datepart（）などの組み込み関数を使用してください。

「クライアントアプリケーションRETRIEVEは、特定の日付セットのすべてのメモをどのように言うことができますか？」

開始日と終了日というWHERE句を使用してクエリを実行する。BETWEEN

'Note'フィールドをvarchar（n）[n最大8000まで）として宣言します。定義された最大サイズではなく、ノートが占めるスペースのみを使用します。

于 2009-09-21T05:13:35.173 に答える
1

アプリケーションが日付を選択し、その日付に関連するすべてのメモを（排他的または部分的に）取得する必要がある場合は、DateTimeデータ型を使用して日付を保存する必要があります。

メモのビジネスメモが数日にわたる可能性がある場合は、NOTESテーブルEFFECTIVE_DATEにEXPIRY_DATEDateTime列が必要です。日付は同じ日でも、2、3日離れていてもかまいません。

NOTESメモのテキスト/本文を定期的な日（つまり、1月1日、13日、21日）に適用する場合は、、、およびの2つのテーブルが必要になりNOTE_ACTIVITYます。 NOTE_ACTIVITYnote_idと、有効日および有効期限が含まれます。データベース内の他の方法で、単一のテキスト本文に関連付けられた散発的な日付をどのようにサポートできるかわかりません。

于 2009-09-21T05:18:02.747 に答える
1

私は個人的にこれを2つのテーブルに分割します

NOTE
int Id
varchar NoteText

NOTEACTIVITY
int Id
DateTime ActivityDate
int NoteId

これにより、クエリがシンプルになり、将来的に十分な柔軟性が得られます。これは、メモが3つの日付に適用される場合、メモテーブルに1つのエントリがあり、NoteActivityテーブルに3つのエントリがあることを意味します。いくつかの点で、既存の設計でこの問題が発生する可能性があります。クライアントが毎月1日にメモを適用したい場合、行（メモを含む）を12回複製しますか？

または、メモのビットマップのアイデアが正しい方法であると既に判断している場合は、ビットマップの代わりに曜日番号を保存することを検討してください。そうすれば、「[1][5][30]」を保存できます。これにより、たとえば、その列に「[5]」を含む行を検索することで、クエリの実行が容易になる場合があります。

于 2009-09-21T07:14:05.270 に答える