SQL Server - colonne d'identité au format

Question

Je voudrais avoir une colonne de clé primaire dans une table qui est formaté comme FOO-BAR- [numéro d'identité], par exemple:

FOO-BAR-1 
FOO-BAR-2 
FOO-BAR-3 
FOO-BAR-4 
FOO-BAR-5 

peut SQL Server faire? Ou dois-je utiliser C# pour gérer la séquence? Si c'est le cas, comment puis-je obtenir la prochaine partie [numéro d'identité] en utilisant EntityFramwork?

Merci

EDIT:

que je devais faire c'est parce que cette colonne représente un identifiant unique d'un avis envoyer aux clients.

• FOO sera une chaîne constante
• BAR sera différent en fonction du type de l'avis (que ce soit de détection, d'avertissement ou d'application)

est-il donc préférable d'avoir juste une identité int colonne et ajouter les valeurs dans Business Logic Layer en C#?

Answer 1

Si vous voulez que ce champ 'composited' dans vos rapports, je vous propose:

1. utilisation INT champ IDENTITY PK dans le tableau
2. Créer une vue pour cette table. Dans cette vue, vous pouvez en outre générer le champ que vous souhaitez utiliser vos chaînes et types.
3. Utilisez cette vue dans vos rapports.

Mais je pense toujours, qu'il y a un gros problème avec la conception DB. J'espère que vous allez essayer de le reconcevoir en utilisant la normalisation.

Answer 2

Vous pouvez définir n'importe quoi comme PK dans une table. Mais dans ce cas, je mettrais IDENTITY juste à un int auto-incrémentant et manuellement l'ajout de FOO-BAR- dans le SQL, BLL, ou UI en fonction de la raison pour laquelle il est utilisé. S'il existe une raison métier pour FOO et BAR, vous devez également les définir comme valeurs dans votre ligne DB. Vous pouvez ensuite créer une clé dans la base de données entre les deux trois colonnes en fonction de la raison pour laquelle vous utilisez réellement les valeurs.

Mais IMO Je ne pense vraiment pas qu'il y ait vraiment de raison de concaténer un ID de cette façon et de le stocker comme tel dans la BD. Mais là encore, je n'utilise vraiment qu'un int comme identifiant.

Answer 3

Une autre option consisterait à utiliser ce que l'on appelait une ancienne équipe appelée codes et table de valeurs. Nous ne l'utilisons pas précisément cela (nous l'avons utilisé en lieu et place des identités auto-incrémentées pour empêcher discordances d'environnement pour certains tableaux clés), mais ce que vous pouvez faire est la suivante:

1. Créer une table qui a rangée pour chacune de vos catégories. Deux colonnes (ou plus) dans la rangée - minimum du nom de la catégorie et du numéro suivant. Lorsque vous insérez un enregistrement dans l'autre table, vous exécutez un proc stocké pour obtenir le prochain numéro d'identité disponible pour cette catégorie, incrémentez le nombre dans la table de codes et de valeurs de 1 et concaténez la catégorie et le numéro ensemble pour votre insertion.

Cependant, si vous êtes table principale est une table à haut volume avec beaucoup d'inserts, il est possible que vous pourriez vous retrouver avec des trucs hors séquence. Quoi qu'il en soit, même si ce n'est pas un volume élevé, je pense que vous feriez mieux de réexaminer pourquoi vous voulez faire cela, et voir s'il y a une autre meilleure façon de le faire (comme avoir la couche de gestion) ou UI le faire, comme d'autres l'ont suggéré).

Answer 4

Il est tout à fait possible en utilisant la colonne calculée comme suit:

CREATE TABLE #test (
    id INT IDENTITY UNIQUE CLUSTERED, 
    pk AS CONCAT('FOO-BAR-', id) PERSISTED PRIMARY KEY NONCLUSTERED, 
    name NVARCHAR(20) 
) 

INSERT INTO #test (name) VALUES (N'one'), (N'two'), (N'three') 

SELECT id, pk, name FROM #test 

DROP TABLE #test 

Notez que pk est réglé sur NONCLUSTERED exprès parce qu'il est de type VARCHAR, alors que le champ d'identité, qui sera unique de toute façon, est réglé sur UNIQUE GRAPPÉ.