1

レコードがデータベースに保存されるように、このデータベースと c# アプリを設計しています。ここで、3 人の営業担当者がいて、それぞれに厳密なローテーションでレコードを割り当てて、同じ量のレコードに取り組む必要があるとします。

Recordsこれまでに行ったことは、という名前のテーブルとという名前のテーブルを作成することでしSalesPersonた。レコードにはid、外部キーとして営業担当者があり、別の列には、割り当てられているエージェントを示し、この列をインクリメントします。

これは良いデザインだと思いますか。そうでない場合、アイデアを教えていただけますか?

4

3 に答える 3

2

これを行うには、分析関数ROW_NUMBERとを使用NTILEします (RDBMS がそれらをサポートしていると仮定します)。このようにして、使用可能な各営業担当者に 1 から増加する疑似 ID を割り当て、未割り当ての各レコードにこれらの疑似 ID の 1 つをランダムに割り当てて、営業担当者間で均等に割り当てることができます。実際の ID ではなく疑似 ID を使用すると、SalesPersonIDフィールドが連続していなくてもかまいません。例えば

-- CREATE SOME SAMPLE DATA
DECLARE @SalesPerson TABLE (SalesPersonID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, Name VARCHAR(50) NOT NULL, Active BIT NOT NULL)
DECLARE @Record TABLE (RecordID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, SalesPersonFK INT NULL, SomeOtherInfo VARCHAR(100))

INSERT @SalesPerson VALUES ('TEST1', 1), ('TEST2', 0), ('TEST3', 1), ('TEST4', 1);
INSERT @Record (SomeOtherInfo)
SELECT  Name
FROM    Sys.all_Objects

このサンプル データを使用して、最初のステップは、レコードを割り当てることができる営業担当者の数を見つけることです。

DECLARE @Count INT = (SELECT COUNT(*) FROM @SalesPerson WHERE Active = 1)

次に CTE を使用してウィンドウ関数を含めます (結合句では使用できないため)。

;WITH Records AS
(   SELECT  *,
            NTILE(@Count) OVER(ORDER BY NEWID()) [PseudoSalesPersonID]
    FROM    @Record
    WHERE   SalesPersonFK IS NULL       -- UNALLOCATED RECORDS
), SalesPeople AS
(   SELECT  SalesPersonID, 
            ROW_NUMBER() OVER (ORDER BY SalesPersonID) [RowNumber]
    FROM    @SalesPerson
    WHERE   Active = 1                  -- ACTIVE SALES PEOPLE
)

最後に、疑似 ID ではなく実際の営業担当者 ID でレコード CTE を更新します。

UPDATE  Records
SET     SalesPersonFK = SalesPeople.SalesPersonID
FROM    Records
        INNER JOIN SalesPeople
            ON PseudoSalesPersonID = RowNumber

SQL FIDDLE ですべてを組み合わせる

于 2012-09-20T11:27:56.820 に答える
1

これは、データベース用語「レコード」とオブジェクト/エンティティ「レコード」を使用していると思われるため、非常に混乱します。

ただし、あるテーブルに一意の識別子があり、別のテーブルの外部キーとしても機能するという単純な概念は問題ありません。冗長性を回避します。

正規化の基本

于 2012-09-20T10:53:56.517 に答える
1

ほとんどの場合、DeeMac が言ったとおりです。しかし、あなたRecordがオブジェクトである場合 (つまり、すべての作業の詳細、または販売または取引がある場合)、そのテーブルを分離する必要があります。Recordその特定のオブジェクトのすべての詳細を含むテーブルを用意します。営業担当者に関するすべての詳細を含む別のテーブル「Salesman」を作成します。(良い設計では、このテーブルのポジションの特定のビジネス関連の属性のみを追加します。個人の詳細はすべて別のテーブルに入れます)

あなたの問題のために、2つの別々のテーブルを作成できます。1 つはRecord_Assignment、 を に割り当てる場所RecordですSalesman。このテーブルには、すべてのアクティブなジョブが保持されます。Archived_Record_Assignment過去のすべてのジョブを保持する別のテーブルになります。完了したすべてのジョブをここに移動します。

仕事の均等な割り当てについては、循環的な割り当てが必要だとおっしゃいました。仕事を利用可能なすべての営業担当者に分散させたいのか、それとも特定の数だけに分散させたいのか、私にはわかりません。通常、課題はチームごとに与えられます。SalesTeam仕事を割り当てたい営業担当者のセールスマン ID を含むテーブル ( table など) を作成します (チーム ID を追加します。複数のチームがそれぞれに割り当てられた作業領域または顧客に取り組んでいる場合です。通常はそうです)。新しい仕事を割り当てたい場合はRecord_Assignment、最後のレコードのテーブルをクエリし、セールスマン ID を取得して、SalesTeamテーブル内の次のセールスマンに仕事を割り当てます。割り当ては、ビジネス ロジック (コーディング) を通じて行われます。

私はあなたのシナリオを完全には認識していません。これらはすべて私の憶測ですので、あなたのシナリオで何かおかしいことがあれば教えてください。

幸運を！

于 2012-09-20T13:43:38.510 に答える