Come devo fare per realizzare un “contatore” di campo in SQL Server 2005?

Question

Io sono a conoscenza dei campi di IDENTITÀ, ma ho la sensazione che non posso usare per risolvere il mio problema.

Diciamo che ho più clienti.Ogni cliente ha più ordini.Ogni cliente ha bisogno di avere i loro ordini numerati in sequenza, specifici per loro.

Esempio di struttura di una tabella:

Orders:
OrderID | ClientID | ClientOrderID | etc...

Alcuni esempi di righe di questa tabella:

OrderID | ClientID | ClientOrderID | etc...
1 | 1 | 1 | ...
2 | 1 | 2 | ...
3 | 2 | 1 | ...
4 | 3 | 1 | ...
5 | 1 | 3 | ...
6 | 2 | 2 | ...

So che l'ingenuo modo sarebbe quello di prendere il MAX ClientOrderID per qualsiasi client e utilizzare tale valore per gli Inserti, ma che dovrebbe essere soggetto a problemi di concorrenza.Stavo pensando di utilizzare una transazione, ma io non sono abbastanza sicuro di quello più ampio di isolamento campo di applicazione che può essere utilizzato per questo.Sarò utilizzo di LINQ to SQL, ma ho la sensazione che non pertinenti.

Answer 1

Qualcuno mi corregga se sbaglio, ma fino a quando il MAX () chiamata è nella stessa fase come inserto, non si avrà un problema con la concorrenza.

Quindi, si potrebbe non do

select @newOrderID=max(ClientOrderID) + 1
from orders
where clientid=@myClientID;

insert into ( ClientID, ClientOrderID, ...)
values( @myClientID, @newOrderID, ...);

Ma possono do

insert into ( ClientID, ClientOrderID, ...)
select @myClientID, max(ClientOrderID) + 1, ...
from orders
where clientid=@myClientID;

sto assumendo OrderID è una colonna di identità.

Anche in questo caso, se sono corretto di queste, per favore fatemelo sapere. Preferibilmente con un URL

Answer 2

È possibile utilizzare un modello di Repository per gestire i vostri ordini e lasciarlo controllare il numero di ogni client specifici numero d'ordine. Se si sceglie di implementare correttamente l'OrderRepository potrebbe controllare la concorrenza e il numero dell'ordine prima di salvarlo nel database (lasciate il repository e non il db impostare il numero).

Pattern Repository: http://martinfowler.com/eaaCatalog/repository.html

Answer 3

Una possibilità (anche se non mi piace fare questo) è quello di avere una tabella di ricerca che vi direbbe il più grande numero di ordinazione dato per ogni fornitore. All'interno di una transazione, si sarebbe procurarsi la più recente dal VendorOrderNumber, salvare il nuovo ordine, incrementare il valore nel VendorOrderNumber, transazione di commit.

Answer 4

Questo è uno strano modo per memorizzare i dati, ma se c'è bisogno, non c'è niente built-in che è possibile utilizzare.

Il tuo suggerimento di Max(ClientOrderID) è semplice e abbastanza facile da implementare (seguire Giovanni MacIntyre consigli).Probabilmente funzionerà accettabilmente bene su tabelle con poche migliaia di ordini.La tabella cresce, sarà questo l'approccio del corso di rallentare.

Nick DeVore la suggestione di una tabella di ricerca è un po ' più complessi da realizzare, ma non essere notevolmente influenzato dalla crescita dei dati.

A seconda di dove/quando è effettivamente necessaria la ClientOrderID, si poteva calcolare l'id, quando necessario, come questo:

SELECT *,
ROW_NUMBER() OVER(ORDER BY OrderID) AS ClientOrderID
FROM Orders
WHERE ClientID = 1

Questo presuppone che il ClientOrderIDs sono nella stessa sequenza in cui il Idordine.Senza persistenza dell'ID, è scomodo da utilizzare come chiave di qualsiasi altra cosa.Questo approccio non dovrebbe essere influenzato dalla crescita dei dati.