Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
ASCRUS
Alex.Czech
Start value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Вот когда нужно одно ID на несколько таблиц сразу автоинкрементить - это и есть те самые 5% (о которых я говорил в другом топике), где identity проигрывает

Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем.


Сбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации
27 дек 04, 16:51    [1212620]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ну вот мы и нашли оправдание существования большой статьи :)
27 дек 04, 16:54    [1212634]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
Блин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА!

Огромна для MSSQL. Это уже глобальная тема, на которую нынче принято отвечать "а вот в юконе все будет хорошо". Другой вопрос, что развязывание по времени этих двух событий само по себе может оказаться удобным, если идет какая-нибудь сложная схема со взаимодействием нескольких процессов - мне, правда, такого делать не приходилось.

Другой аспект - секвенсоры позволяют легко и довольно эффективно получить массив будущих id-шников, в то время как @@identity вряд ли столь универсальна.
27 дек 04, 16:55    [1212639]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а всегда ли будет @@identity=IDENT_CURRENT('table_name')+1 после добавления?
и, каким образом мне сдвинуть значение identity? или зарезервировать какой-то промежуток значений для своей транзнакции?
27 дек 04, 16:59    [1212668]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!
Guest
автор
Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем.


а разве у автоинкремента не так-же если я прямо пишу 101 то и запишется 101 а не 3 ?

ЗЫ. в оракле номер берут из сиквенса в тригери а не из другой субд.
27 дек 04, 17:03    [1212688]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Alex.Czech
Сбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации

Хм. Согласитесь, эти две задачи удобнее решать одним полем :)

P.S. Не продумал про сбивание. Слишком зашорен - привык, что "текущее значение" хранится и явно запрашивается-изменяется.
27 дек 04, 17:03    [1212689]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
softwarer
Alex.Czech
Сбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации

Хм. Согласитесь, эти две задачи удобнее решать одним полем :)

P.S. Не продумал про сбивание. Слишком зашорен - привык, что "текущее значение" хранится и явно запрашивается-изменяется.


Соглашусь, конечно... в принципе можно решать и одним полем - типа GUID - если записей немного, иначе производительность падает. Но вообще мне самому идея identity не очень нравится, если честно, sequence несомненно лучше
27 дек 04, 17:06    [1212708]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Yo!
автор
хм.. как-то вы с темы на тему перескакиваете. По поводу того документа и оценки в нем интеграции .Net и MS SQL вы согласны или нет? Если да, то вопрос решен, если нет, это означает что вы не со всем в нем согласны, тогда зачем вы его вообще советовали смотреть?
советовал смотреть чтоб вы вообще представляли в чем есть отличия..
знаете, в отличие от некоторых (не будем показывать пальцем) прежде чем говорить про то что плохо в другой СУБД, я стараюсь в ней разобраться.
27 дек 04, 17:12    [1212750]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
segun
Member

Откуда: Москва
Сообщений: 504
Yo!
например про .net и java я не согласен - мне все равно через врапер или нет запускается моя java, главное чтоб потери в скорости небыло. когда появятся тесты тогда и можно поговорить о преимуществах прямого запуска, а так это просто слова (если не углублятся в сами языки и их конструкции).
почему же просто слова? есть целый ряд статей, в которых написано в каких случаях .NET будет работать быстрее TSQL и наоборот. Они приводились на примере beta2, но тем не менее, даже на этой, совсем не оптимальной по производительности версии сервера .Net показывает себя очень даже неплохо и оправдывает свое присутствие в сервере.
27 дек 04, 17:28    [1212832]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!
Guest
segun
почему же просто слова? есть целый ряд статей, в которых написано в каких случаях .NET будет работать быстрее TSQL и наоборот. Они приводились на примере beta2, но тем не менее, даже на этой, совсем не оптимальной по производительности версии сервера .Net показывает себя очень даже неплохо и оправдывает свое присутствие в сервере.


статьи на всьяпупкин.народ.ру действительно бывают очень интересными, может дадите линк где бы не поламерски организовали тестирование ? только не на словах и пальцах, а нормальные тесты которые я бы мог повторить ?
27 дек 04, 17:33    [1212855]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 softwarer
Про хуже разбираться не скажу - передумал :))

По секвенсам/идентити.
Да, когда нужно обеспечить уникальность счетчика на несколько таблиц одновременно или обеспечить вставку данных с бОльшими значениями, то тут identity хреново подходит, только если через дополнительную таблицу.

-- Tygra's --
27 дек 04, 17:46    [1212890]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
segun
Member

Откуда: Москва
Сообщений: 504
2 Yo!:
вообще-то в статьях как правило код, который при желании можно повторить и проанализировать. Но что-то говорит мне что вы, уважаемый, все равно не станете это делать. У вас есть SQL2k5 beta2? У вас стоит хотя бы SQL2k?
27 дек 04, 17:47    [1212897]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
а всегда ли будет @@identity=IDENT_CURRENT('table_name')+1 после добавления?

Всегда, если никто не успел добавить до того, как вы узнали IDENT_CURRENT('table_name')
автор
и, каким образом мне сдвинуть значение identity? или зарезервировать какой-то промежуток значений для своей транзнакции?

Ну измените текущее значение идентити, а то. что себе оставили, добавляйте с set identity_insert on

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

-- Tygra's --
27 дек 04, 17:50    [1212912]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!
Guest
автор
вообще-то в статьях как правило код, который при желании можно повторить и проанализировать. Но что-то говорит мне что вы, уважаемый, все равно не станете это делать. У вас есть SQL2k5 beta2? У вас стоит хотя бы SQL2k?


ну покажите же наконец эту чудо статью, я заинтригован. я так понимаю я там увижу java код для оракла и аналогичный на .Net для юкона и соответствено замеры скорости ? и там же я так понимаю и увижу то самое превосходство ?
27 дек 04, 18:03    [1212952]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
tygra
Хотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать

Например при копировании ветки дерева
27 дек 04, 18:17    [1213009]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
tygra
Хотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать.

Массовая загрузка данных. Запрос id - довольно дорогая операция, поскольку требует синхронизации на высшем уровне. Соответственно, если сервер занят не только загрузкой, запрашивать по одному номеру на каждую запись - довольно неэффективно.

Полагаю, это справедливо для всех серверов - то есть, я не вижу способа избежать этой проблемы. Ну а масштабы - видны на достаточно простом примере (на пустом сервере).

Connected to Oracle9i Enterprise Edition Release 9.2.0.4.0 

SQL> create sequence a1;
SQL> create sequence a2 nocache;

SQL> declare 
  2    s integer ;
  3  begin
  4    for i in 1..10000 loop select a1.nextval into s from dual ; end loop ;
  5  end ;
  6  /

Executed in 1,813 seconds

SQL> declare
  2    s integer ;
  3  begin
  4    for i in 1..10000 loop select a2.nextval into s from dual ; end loop ;
  5  end ;
  6  /

Executed in 10,282 seconds
27 дек 04, 18:23    [1213026]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
1. SEQUENCE it's cool :), но он не решает проблем с репликацией по большому счету, так как в базе-источнике и базе-приемнике свои значения упомянутого, которые могут также пересекатся, как и identity. Для репликации в идеале надо получать идентификаторы, практически гарантировано, уникальные вне зависимости от сервера, базы и таблицы. Этим требованиям до определенной степени удовлетворяет GUID, но никак не sequence в чистом виде, который по смыслу представляет обычный identity, но в масштабе всей БД, а не отдельной таблицы.

2. Кстати, до стандарта SQL2003 ни о каких SEQUENCE речи не идет, правда, не идет речи и об identity :) , это к тому, что MS SQL пытается не сильно отрыватся от базовых стандартов, что не всегда получается, ровно, как и у всех остальных, разве что Sybase ASA, и то по отрывочным слухам. Здесь можно поверить ACRUS, если он подтвердит, хотя по некоторым примерам, которые он приводил, тоже есть тенденция расширять стандарты ради удобства. Собственно это к тому, что многие возможности выходят за рамки стандарта и производители часто реализуют их по своему. И лучше это или хуже, IMHO, судить сложно. В частности, мне ни разу не приходилось сталкиваться с потребностью создавать сквозную нумерацию через несколько "разношерстных" таблиц за достаточно немалый срок работы с СУБД, и она кажется несколько "искусственной". Если таковая возможность требовалась, то обычно это было связано с тем, что таковые таблицы по смыслу были подчиненными и связаными с "главной" таблицей, в которой и было поле identity, значения которого мигрировали в ключ "подчиненных" таблиц.

3. Если в некоторых случаях был необходим признак, гарантировано уникальный и монотонно возрастающий в пределах БД, например, для отслеживания порядка создания записей из разных таблиц, для этого в MS SQL достаточно использовать тип timestamp, который не имеет ровно никакого отношения ко времени, а представляет тупо и монотонно возрастающее binary(8) значение. У него есть один "минус", оно изменяется при каждом обновлении строки, так как в некотором смысле представляет собой версию строки, и поэтому является его же "плюсом". При необходимости "помнить" первоначальное значение полученное при вставке, его можно сохранить в другом поле типа binary(8), триггером при вставке, например.
Это ни плохо, ни хорошо, это так.

4. Потребность получить заранее значение типа autoincrement, до реальной вставки в таблицу, чтобы затем его использовать, может привести с одной стороны к тому, что разные пользователи могут получить одно и то же значение, что в дальнейшем может привести к конфликту при вставке. С другой стороны, если после каждого чтения значения такого счетчика оно инкрементируется, то возникает опасность быстрого "исчерпания" в случае неверного кодирования, например при "зацикливании". Опять же, если необходимо получить диапазон идентификаторов типа identity, то никто не мешает получить последнее вставленное значение, а затем "сдвинуть" его на нужный шаг, зная, что "пропущенный" промежуток можно использовать позже, но это на любителя и при острой необходимости.

P.S. Sorry за многословность, в этом виноваты стакан водки и коньяка :)
28 дек 04, 02:24    [1213396]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 906
softwarer

Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity.

вот сижу и думаю, как это у меня работает репликация на identity с разделением диапазонов по серверам? ведь не должна, а работает....
наверное мне только кажется, что у меня mssql, а реально там крутится oracle.
;)
28 дек 04, 05:59    [1213421]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 906
ASCRUS

Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем.

если пришел по репликации - и будет равняться 3.
куда он денется.
28 дек 04, 06:05    [1213422]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Dik76
Member

Откуда: Казань
Сообщений: 1517
Возвращаясь к первоначальной теме... dimitr какие выводы?
28 дек 04, 11:10    [1214039]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
А выводы обязательно должны быть? ;-) По общим методам использования TT тут много интересного сказали, и почти все это хорошо коррелируется с моим собственным опытом. Насчет чрезмерной любви сиквелистов к TT я, пожалуй, соглашусь с выводами ASCRUS'а, ибо внятных доказательств обратного мы так и не услышали. Все еще более-менее спорной остается необходимость в CLTT... А так, в целом, неплохо поговорили... хотя без флейма все равно не обошлось ;-)))

К слову, какие дополнительные атрибуты CLTT и DLTT поддерживают сервера? Я имею ввиду констрейнты, индексы, триггеры. Имеет ли практический смысл вообще иметь триггеры для DLTT? Или те же FK? И еще один нюанс - я так понимаю, что опции DELETE/PRESERVE ROWS для DLTT особого смысла не имеют? Или все же множество транзакций внутри ХП является общепринятой практикой?
28 дек 04, 11:34    [1214169]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Dik76
Member

Откуда: Казань
Сообщений: 1517
dimitr
А выводы обязательно должны быть? ;-)

Если это будет в FB 2.0, то просто интересно :)
28 дек 04, 11:59    [1214288]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ChA
1. SEQUENCE it's cool :), но он не решает проблем с репликацией по большому счету, так как в базе-источнике и базе-приемнике свои значения упомянутого, которые могут также пересекатся, как и identity.

Решает. Я даже написал, как именно. После этого пересечься они могут только в результате "действий руками" - ну а тут и GUID не спасет.

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

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

ChA
2. Кстати, до стандарта SQL2003 ни о каких SEQUENCE речи не идет, правда, не идет речи и об identity :) , это к тому, что MS SQL пытается

Хм. Если бы сервера не отрывались от стандартов - мы бы их сейчас ругали совсем не за детали репликации :)

ChA
В частности, мне ни разу не приходилось сталкиваться с потребностью создавать сквозную нумерацию через несколько "разношерстных" таблиц за достаточно немалый срок работы с СУБД, и она кажется несколько "искусственной". Если таковая возможность требовалась, то обычно это было связано с тем, что таковые таблицы по смыслу были подчиненными и связаными с "главной" таблицей, в которой и было поле identity, значения которого мигрировали в ключ "подчиненных" таблиц.

Вы другими словами сказали то же самое - вводить искусственную таблицу с identity. Просто представьте себе, что "главная" таблица не содержит ничего, кроме этого id - ну и, быть может, еще пары атрибутов, типа "создатель" и "дата создания", ради которых не стоит городить таблицу.

Что касается примера - пожалуй, самый "горячий" будет связан с популярным желанием сделать таблички физ-юр лиц со сквозными id - дабы "одним полем id адресовать обе таблицы". Я здесь не имею в виду поднимать тему "насколько это хорошо"; просто наиболее навязшее в зубах.

ChA
3. Если в некоторых случаях был необходим признак, гарантировано уникальный и монотонно возрастающий в пределах БД, например, для отслеживания порядка создания записей из разных таблиц, для этого в MS SQL достаточно использовать тип timestamp, который не имеет ровно никакого отношения ко времени, а представляет тупо и монотонно возрастающее binary(8)

Согласен, это вполне удобный для репликации id. По крайней мере пока не пойдет вопрос переполнения :)

ChA
Это ни плохо, ни хорошо, это так.

Хм. А прокомментируете то, что я уже упоминал - если я правильно понимаю, такие манипуляции на триггерах связаны с необходимостью второй раз update-ить ту же запись (и соответственно с дополнительной нагрузкой).

ChA
4. Потребность получить заранее значение типа autoincrement, до реальной вставки в таблицу, чтобы затем его использовать, может привести с одной стороны к тому, что разные пользователи могут получить одно и то же значение, что в дальнейшем может привести к конфликту при вставке.

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

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

Хм. В случае неверного кодирования можно получить абсолютно любые результаты - даже верные, если повезет. Не понимаю, что следует из этого аргумента. Реально "теряется" весьма немного id-шников, и, полагаю, если бы они вычислялись при вставке, терялись бы настолько же часто - поскольку основной причиной потери является rollback.

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

Эта проблема, к сожалению, нормально решается только в Interbase - правда, там свои минусы. Тем не менее, возможность получить id до вставки весьма актуальна - в качестве простого примера можно назвать работу с мастер-деталью с клиента.
28 дек 04, 12:01    [1214297]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
andy st
вот сижу и думаю, как это у меня работает репликация на identity с разделением диапазонов по серверам? ведь не должна, а работает....
наверное мне только кажется, что у меня mssql, а реально там крутится oracle.
;)

Думаю, реально у Вас крутится решения наподобие предложенного в упомянутой мной статье. Это решение кажется мне.. неоправданно сложным и неудобным - например, с моей точки зрения, диапазоны id вообще не слишком удачная идея.
28 дек 04, 12:03    [1214310]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Dik76
Если это будет в FB 2.0, то просто интересно :)


Не надо делать из FB2 всеобщего счастья. Что будет - то будет, остальное - потом. Мне до пенсии еще далеко ;-)
28 дек 04, 12:06    [1214325]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить