3

私は現在、ユーザーが自分のニーズに基づいてチケットを送信できるチケットシステムに取り組んでいます。つまり、部門「A」がチケットを送信する場合、選択したカテゴリに関連する詳細とともに、特定のタイプの問題カテゴリ（「サプライ」や「プリンタ」など）を持つことができます。私は部分的なデータベース設計をレイアウトしました、そして私はそれについてのいくつかのフィードバックを探していました。自分でゼロからシステムを構築したことは一度もないので、少し緊張しています。

これが私のデータベース設計のドラフトバージョンです

問題表

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

EquipmentIssueDetailsテーブル

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

SupplyIssueDetailsテーブル

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

NetworkIssueDetailsテーブル

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

ノートテーブル

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------

前もって感謝します

4

4 に答える 4

3

問題テーブルを分割して、問題と割り当てを分けたいと思います。また、課題タイプ テーブルを追加し、IssueTypeId 列を課題に追加します。

問題

Id、IssueTypeId、CreatedBy、CreateDate、ステータス、所有者

問題の種類

ID、名前

課題

Id、IssueId、AssignedTo、AssignmentDate、Active

これにより、後で必要になった場合に、複数の人が問題に割り当てられるようになります。また、Issue から割り当て解除された人々の履歴を記録することもできます。問題タイプのエントリは次のようになります: 1: 機器、2: 供給、3: ネットワーク

いくつかの異なる問題タイプを管理するのは問題ないかもしれませんが、問題が多い場合は、Ikke が提案するように「詳細」テーブルをキー/値テーブル アプローチに置き換える方がよい場合があります。

于 2010-03-26T19:35:06.147 に答える
2

あなたのデザインは素晴らしいです。各タイプの問題の詳細を含む個別の表は、まさに正しいアプローチです。

キーと値のペアが必要だと考える人のアドバイスに従わないでください。このようなアプローチはいくつかのことを容易にしますが、他のことをしようとするとすぐに悪夢に変わります。自由に使える完全なRDBMSの力があります。これを使って！

各表の各行は、世界に関する真の命題を表しています。DB設計が追跡しようとしている重要な現実を反映できるほど、より良い結果が得られます。

将来、詳細を追跡する必要があることが判明した場合は、列を追加してください。追加の問題タイプがあることが判明した場合は、さらにテーブルを追加します。課題タイプのテーブルは何も追加しません。

この原則に従うと、レポートを作成したり、このデータの分析を行ったりするときに大きな利益が得られます。

問題ごとに複数の担当者を許可するか、割り当ての履歴を追跡することについて、OGのアドバイスに従うことを検討する必要があります。それは、システムがどのように使用されるか、または何を報告する必要があるかによって異なります。保存されなかったデータについてはレポートできないことに注意してください。

于 2010-03-26T20:02:32.093 に答える
1

設計するときは、このデータをどのように使用するかを考え始めます。実行する必要があるレポートの種類、課題の変更を通知する方法、タスクに割り当てる人をどのように選択するか (仕事に利用できる人やそのスキル セットを格納するテーブルが必要になる場合があります (どのような種類のタスクに割り当てることができるか)、どのような種類の添付ファイルを許可する必要があるか、その情報をどこに保存する必要があるか (スクリーン ショットは、問題の解決に大いに役立ちます)。アプリケーションのダウン? 何らかの種類のデータ監査が必要ですか? 特定の種類の問題で監督者による承認が必要ですか? 人を自動的に割り当てられるか、または誰が誰であるかを決定する前に、彼らがすでに持っているものを追跡する必要がありますか?利用可能です。物事がいつ遅れているかを判断するために、タスクを完了する必要があるデータを判断できるようにしたいですか? 特定の部署は特定の種類のチケットしか送信できないとのことですが、そのデータを保存するテーブルはどこにありますか? 言い換えれば、あなたは本当に核心に取り掛かり、要件を実行する必要があります.

ところで、誰にもキー値ストアについて話させないでください。これは、リレーショナル データベースにデータを格納するための絶対に最悪の方法です。パフォーマンスの問題が発生するだけでなく、フィールドに適切に制限を設定する能力 (フィールドが必須かどうかなど) が大幅に失われ、頻繁な変換が必要な一部の情報に対して不適切なデータ型の選択を余儀なくされます。関数を実行するための正しいタイプのデータ。

于 2010-03-26T20:18:53.270 に答える
1

これは可能な解決策ですが、あまり柔軟ではありません。新しいタイプの問題が発生した場合は、データベースを変更する必要があります。

もう 1 つの解決策は、キーと値のペアのフィールドを持つ 1 つのテーブルにすべての異なるテーブルを配置することです。このアプローチの欠点は、アプリケーションでキーを定義する必要があり、データベースにはすべての情報が存在するかどうかを確認する手段がないことです。

これはあなたがしなければならない考慮事項です。もっと解決策があるかもしれませんが、今思いつくものはありません。

于 2010-03-26T19:34:58.707 に答える