Автоинкремент своими руками

← →
Term (2004-11-18 10:23) [0]

Значит проблема такая нужно автоинкремент заполнять определённым обпразом скажем чтобы генерились значения типа 1.1, 1.2 и т.д. 1. -префикс для всей базы, использую MSSQL2000, есть в данной СУБД генераторы такие или набодобие как в FB. чтобы из них получить уникальное значение а скажем в тригере слепить нужное значение и вставить в поле???

← →
Ega23 © (2004-11-18 10:27) [1]

Нет. Самому генерить надо. Или в ХП проавила прописать.

З.Ы. А нафига? Сделай ключ первичный как стандартный IDENTITY + добавь ещё одно поле, куда и пиши свои дроби. Я бы так сделал, по крайней мере.

← →
Johnmen © (2004-11-18 10:27) [2]

автоинкриментное поле + вычисляемое поле
А вообще - всё это от лукавого...

← →
ЮЮ © (2004-11-18 10:27) [3]

>1. -префикс для всей базы
ну и зачем? эту "1." достаточно рисовать, а не хранить

>значения типа 1.1, 1.2
а какого они будут типа?

← →
Nikolay M. © (2004-11-18 10:27) [4]

Умножить на 10^х. Что мешает для каждой базы назначить стартовый номер генерации (Identity seed) кратный, скажем, миллиону?

← →
Term (2004-11-18 10:30) [5]

> а какого они будут типа?

естесвенно символы

← →
Ega23 © (2004-11-18 10:31) [6]

primary key - CHAR????
Фи, как некультурно....

← →
ЮЮ © (2004-11-18 10:33) [7]

А потом, почему у меня
1.1
1.10
1.2
я хочу
1.1
1.2
1.10
:(

← →
Nikolay M. © (2004-11-18 10:40) [8]

> Term (18.11.04 10:30) [5]
> > а какого они будут типа?
> естесвенно символы

Чушь какая... Да еще естественно...
Вот вечно изобретают свои велосипеды.

> ну и зачем? эту "1." достаточно рисовать, а не хранить

Имхо, ему это для репликации (скорее всего опять же самопальной) нужно.

← →
Соловьев © (2004-11-18 10:43) [9]

> А потом, почему у меня
> 1.1
> 1.10
> 1.2
> я хочу
> 1.1
> 1.2
> 1.10

А так
1.01
1.02
1.10
?

← →
Anatoly Podgoretsky © (2004-11-18 10:44) [10]

Для репликации надо использовать другие методы, а не городить велосипед с квадратными колесами.

← →
Term (2004-11-18 10:45) [11]

> Имхо, ему это для репликации (скорее всего опять же самопальной)
> нужно.

енто точно просто без самопальной не обойтись

← →
Term (2004-11-18 10:47) [12]

> Для репликации надо использовать другие методы, а не городить
> велосипед с квадратными колесами.

подскажи круглые

← →
Term (2004-11-18 10:49) [13]

просто еще такая фигня иногда значение сгенеренного поля нужно будет поменять

← →
Term (2004-11-18 10:50) [14]

> primary key - CHAR????
> Фи, как некультурно....

я про primary key ничего не говорил вроде

← →
Term (2004-11-18 11:03) [15]

народ так есть способ это делать нормально, без хитростей от лукавого :)

← →
Nikolay M. © (2004-11-18 11:12) [16]

> Term (18.11.04 11:03) [15]
> народ так есть способ это делать нормально, без хитростей
> от лукавого :)

Да. Штатными средствами генерации автоинкремента и репликации.

← →
Term (2004-11-18 11:14) [17]

> Да. Штатными средствами генерации автоинкремента и репликации

штатные не годятся, нет постоянного соединения между двумя серверами, а данные перегонять нужно, поэтому изобретаются колёса по возможности более круглые

← →
vuk © (2004-11-18 11:20) [18]

У нас используется ручная генерация искусственных ключей. Дело в том, что во-первых генерация искусственных ключей может происходить по какому-либо хитрому закону (пример - счетчик * 10 + код_подразделения или еще как-то), а во-вторых в старых версиях MSSQL был баг, когда слетали identity и значения начинали генериться повторно. С тех пор соломку стелим - проблем нет.

С реализацией проблем не вижу. Есть табличка с двумя полями (имя таблицы + счетчик). Перед вставкой записи генерится ID для нужной таблицы и вставляется вместе с остальными данными. Правда есть одна тонкость - у нас вся работа с данными ведется через хранимые процедуры и клиенты не имеют прямого доступа к таблицам. Поэтому все операции с данными находятся под контролем.

to Term (18.11.04 10:49) [13]:
>просто еще такая фигня иногда значение сгенеренного поля нужно
>будет поменять
А вот это в корне неправильно. Идентификатор, он на то и идентификатор, чтобы быть неизменным.

← →
Anatoly Podgoretsky © (2004-11-18 11:22) [19]

Репликация не подразумевает постоянное соединение, она даже таким понятием и не фигурирует. А поскольку речь про MSSQL2000 то у нее есть и ключи расчитаные на репликацию.
Рекомендуется внимательно почить BOL как по ключам/типам, так и по репликации.

← →
sniknik © (2004-11-18 11:26) [20]

именно так как в вопросе
CREATE TABLE Table1 (ID INT IDENTITY(10, 1), FioID AS Cast(Cast(ID AS Money)/10 AS Char(10) ), Name VarChar(100))
FioID - нужное поле

← →
Term (2004-11-18 11:32) [21]

> А вот это в корне неправильно. Идентификатор, он на то и
> идентификатор, чтобы быть неизменным

я знаю просто я не озвучил всей задачи

> MSSQL2000 то у нее есть и ключи расчитаные на репликацию.

значение ключа ИМЕЕТ значение и в другой БД не должно меняться такова задача, поэтому всю кашу и заварил

← →
Anatoly Podgoretsky © (2004-11-18 11:42) [22]

Term (18.11.04 11:32) [21]
значение ключа ИМЕЕТ значение и в другой БД не должно меняться такова задача, поэтому всю кашу и заварил

И это GUID, такой тип там есть и он устойчив к репликации и уникальность, название немного другое, проверь по BOL

← →
sniknik © (2004-11-18 11:45) [23]

> название немного другое ...
uniqueidentifier

← →
Nikolay M. © (2004-11-18 11:59) [24]

> Term (18.11.04 11:32) [21]
> > А вот это в корне неправильно. Идентификатор, он на то
> > и идентификатор, чтобы быть неизменным
>
> я знаю просто я не озвучил всей задачи

Тренируешь наши телепатические способности? :)
А озвучить хотя бы в общем задачу? Что за манера, спрашивать А, а получив правильный ответ говорить, что вообще-то имелось ввиду Б?

← →
Term (2004-11-18 12:15) [25]

> И это GUID, такой тип там есть и он устойчив к репликации
> и уникальность, название немного другое, проверь по BOL

я в курсе, не совсем же лентяй .

просто по гуиду нельзя определить с какого сервака эта запись пришла, а это тоже нужно, в общем не с проста я это замыслил, т.е. как я понял из всего выше сказанного вставку надо делать только с помошью хранимых процедур??? и в них получать нужные значения, сделать автоикремент и по его значению получать составное поле. я всё прально понял???

← →
Term (2004-11-18 13:05) [26]

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

← →
Nikolay M. © (2004-11-18 13:05) [27]

> просто по гуиду нельзя определить с какого сервака эта запись
> пришла

Это тебе с товарищем нужно объединяться :)
http://delphimaster.net/view/15-1100700493/

> вставку надо делать только с помошью хранимых процедур

Ну вот, теперь еще хранимые процедуры почему-то возникли...

Я не пойму, что мешает разделить все значения int на несколько диапазонов и на каждом сервере генерить автоинкремент только в пределах позволенного ему диапазона?

> Я не пойму, что мешает разделить все значения int на несколько диапазонов и на каждом сервере генерить автоинкремент только в пределах
> позволенного ему диапазона?
а дополнительное поле с номером подразделения кто мешает завести? это все предлагалось, но вместо принятия логичного/и обсуждения конкретного, вылезли выводы по каким то ХП ([25]), а логичное упорно игнорируется.

← →
Term (2004-11-18 14:01) [29]

> а дополнительное поле с номером подразделения кто мешает
> завести? это все предлагалось, но вместо принятия логичного/и
> обсуждения конкретного, вылезли выводы по каким то ХП ([25]),
> а логичное упорно игнорируется.

ничего не игнорируется,

> Правда есть одна тонкость - у нас вся работа с данными ведется
> через хранимые процедуры и клиенты не имеют прямого доступа
> к таблицам. Поэтому все операции с данными находятся под
> контролем.

отсюда взялись ХП.

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

> на основе identity не годиться, т.к. идентити нельзя править

Это твое очередное "естественно"? Может, БОЛ почитать?

> а дополнительное поле с номером подразделения кто мешает
> завести?

Или так, собственно, не суть важно. Похоже, автор дейстувет по принципу: нам чужие велосипеды не нужны - мы свой придумаем...

to Nikolay M. © (18.11.04 13:05) [27]:
>Я не пойму, что мешает разделить все значения int на несколько
>диапазонов и на каждом сервере генерить автоинкремент только в
>пределах позволенного ему диапазона?
Можно, но диапазоны должны быть достаточно широкими, чтобы исключить пересечения. Иной раз это не очень удобно.

to sniknik © (18.11.04 13:38) [28]:
>а дополнительное поле с номером подразделения кто мешает
>завести?
А одно другого не исключает. Просто при наличии составного ключа менее удобно делать ссылки при построении FK. То есть наличие естественного ключа не исключает удобства наличия искусственного.

← →
Term (2004-11-18 14:47) [32]

> Это твое очередное "естественно"?

нет это противоестественно :))) но требуется

"противоестественным" способом можно и автоинкремент изменить, читайте BOL. (в который раз? ;о))

> vuk © (18.11.04 14:46) [31]
> Можно, но диапазоны должны быть достаточно широкими, чтобы
> исключить пересечения. Иной раз это не очень удобно.

Я отнюдь не навязыавл этот способ, просто интересовали причины "против".

> Term (18.11.04 14:47) [32]
> нет это противоестественно :)))

А изменять твои "1.2" - это более "естественно"?

← →
Term (2004-11-18 15:38) [35]

> противоестественным" способом можно и автоинкремент изменить,
> читайте BOL. (в который раз? ;о))

я это тоже читал там есть свои грабли, как я понял после этого меняется значение которое он выдаст при следующей вставке. Т.Е. если было 1000 я его поменял на 2000 то след будет 2001, я так понял

Неправильно ты понял. Читай про SET IDENTITY_INSERT

to Nikolay M. © (18.11.04 15:37) [34]:
>просто интересовали причины "против".
Основная причина против - если идентификаторы используются не только для внутренних связей данных, а например являются артикулами товаров (кодами заказов, продаж и т.п.), то, я думаю, понятно, что короткими идентификаторами оперировать проще, чем длинными. Но если разбивать идентификаторы на диапазоны по подразделениям и пытаться уйти от пересечений диапазонов, то длинных идентификаторов избежать вряд ли удасться.

> vuk © (18.11.04 15:46) [37]

Таких ситуаций я и сам могу придумать с десяток, меня интересовало, что конкретно происходит у автора :)

> Ega23 © (18.11.04 15:40) [36]

Ты все-таки не вытерпел :)))

to Nikolay M. © (18.11.04 16:08) [38]:
Что интересовало - это я понял. Просто как вариант привел примеры из жизни. Не придумал.

Автоинкремент своими руками Найти похожие ветки