Sql Server Столбец с автоматически сгенерированными данными - PullRequest
0 голосов
/ 11 апреля 2009

У меня есть таблица клиентов, и мое требование - добавить новый столбец varchar, который автоматически получает случайное уникальное значение каждый раз, когда создается новый клиент.

Я подумал о написании SP, который рандомизирует строку, затем проверил и заново сгенерировал, если строка уже существует. Но для интеграции SP в процесс создания записей о клиенте потребовались бы транзакционные средства SQL на уровне кода, которых я бы хотел избежать.

Помогите пожалуйста?

редактирование: Я должен был подчеркнуть, что varchar должен быть длиной 5 символов с числовыми значениями между 1000 и 99999, а если число меньше 10000, наберите 0 слева.

Ответы [ 6 ]

3 голосов
/ 11 апреля 2009

если это должен быть varchar, вы можете наложить уникальный идентификатор на varchar.

для получения случайного уникального идентификатора выполните NewId ()

вот как вы его разыгрываете:

CAST(NewId() as varchar(36))

EDIT

согласно вашему комментарию к @Brannon:

Вы говорите, что НИКОГДА не будете иметь более 99 000 записей в таблице? если это так, просто сделайте ваш PK столбцом идентификаторов, начните его с 1000 и позаботьтесь о заполнении нулями в вашей бизнес-логике.

1 голос
/ 11 апреля 2009

Я думаю, что ответ Майкла с автоинкрементом должен работать хорошо - ваш клиент получит «01000», затем «01001», а затем «01002» и т. Д.

Если вы хотите или должны сделать это более случайным, в этом случае я бы предложил вам создать таблицу, содержащую все возможные значения, от "01000" до "99999". Когда вы вставляете нового клиента, используйте технику (например, рандомизацию), чтобы выбрать одну из существующих строк в этой таблице (ваш пул еще доступных идентификаторов клиентов), использовать ее и удалить из таблицы.

Все остальное со временем станет действительно плохим. Представьте, что вы израсходовали 90% или 95% имеющихся у вас идентификаторов клиентов - попытка случайным образом найти одну из немногих оставшихся возможностей может привести к почти бесконечной повторной попытке «это сделано? Да -> попробовать следующую».

Марк

1 голос
/ 11 апреля 2009

С вашим редактированием / обновлением звучит так, как будто вам нужно это автоинкремент и некоторые отступы.

Ниже представлен подход, который использует фиктивную таблицу, затем добавляет столбец IDENTITY (при условии, что у вас его нет), который начинается с 1000, а затем использует вычисляемый столбец, чтобы дать вам некоторые отступы, чтобы все работало как вы просили.

CREATE TABLE Customers (
    CustomerName varchar(20) NOT NULL
)
GO

INSERT INTO Customers 
SELECT 'Bob Thomas' UNION
SELECT 'Dave Winchel' UNION
SELECT 'Nancy Davolio' UNION
SELECT 'Saded Khan'
GO

ALTER TABLE Customers
    ADD CustomerId int IDENTITY(1000,1) NOT NULL
GO 

ALTER TABLE Customers
    ADD SuperId AS right(replicate('0',5)+ CAST(CustomerId as varchar(5)),5) 
GO

SELECT * FROM Customers
GO

DROP TABLE Customers
GO
1 голос
/ 11 апреля 2009

Этот вопрос вызывает у меня то же чувство, когда пользователи не говорят мне, что они хотят сделать, или почему, они просто хотят рассказать мне, как это сделать.

«Случайный» и «Уникальный» являются противоречивыми требованиями, если только вы не создадите последовательный список, а затем случайным образом не выберете его, удалив выбранное значение.

Но в чем проблема, для решения которой она предназначена?

1 голос
/ 11 апреля 2009

Должны ли случайные строковые данные иметь определенный формат? Если нет, то почему бы не использовать уникальный идентификатор?

insert into Customer ([Name], [UniqueValue]) values (@Name, NEWID())

Или используйте NEWID() в качестве значения по умолчанию для столбца.

EDIT: Я согласен с @rm, использую числовое значение в вашей базе данных и обрабатываю преобразование в строку (с дополнением и т. Д.) В коде.

0 голосов
/ 11 апреля 2009

Попробуйте это:

ALTER TABLE Customer ADD AVarcharColumn varchar(50) 
CONSTRAINT DF_Customer_AVarcharColumn DEFAULT CONVERT(varchar(50), GETDATE(), 109)

Возвращает дату и время с точностью до миллисекунд, чего будет достаточно в большинстве случаев.

Вам действительно нужно уникальное значение?

...