Есть ли спецы по MS SQL server

[sansa]

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

-- Получаем номер "базы", на которой расположен наш завод
SELECT @wid = wp_id FROM plants WHERE id = @pid;
-- Создаем "ручной" талон
INSERT INTO tickets (volume, wp_id, car_no, in_no) VALUES (@kl, @wid, '---', '-1');
SET @tid = IDENT_CURRENT('tickets');
-- Обновляем статус талона на "Выполняется"
INSERT INTO v_te (ticket_id, st, plant_id, line_id) VALUES (@tid, 3, @pid, @lid);

Она работает, но идент поле (id, тут не показано) получается с приращением +2, а не +1, как описано в DDL таблицы. Тригеров никаких нет. Чо за дела?

В BOL сказано, что такие приращения могут быть из-за ошибок в инсерте, но здесь ошибок не происходит.
Нипаанятно!

[2man]

id - AUTO_INCREMENT ? на ум приходит сделать выборку select max(id) перед инсертом и вставлять id "руками"

---------- Сообщение добавлено в 19:18 ---------- Предыдущее сообщение было в 19:18 ----------

тьфу, не глянул ms sql... ну смысл ты понял

[AlikForever]

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

-- Получаем номер "базы", на которой расположен наш завод
SELECT @wid = wp_id FROM plants WHERE id = @pid;
-- Создаем "ручной" талон
INSERT INTO tickets (volume, wp_id, car_no, in_no) VALUES (@kl, @wid, '---', '-1');
SET @tid = IDENT_CURRENT('tickets');
-- Обновляем статус талона на "Выполняется"
INSERT INTO v_te (ticket_id, st, plant_id, line_id) VALUES (@tid, 3, @pid, @lid);

Она работает, но идент поле (id, тут не показано) получается с приращением +2, а не +1, как описано в DDL таблицы. Тригеров никаких нет. Чо за дела?
В BOL сказано, что такие приращения могут быть из-за ошибок в инсерте, но здесь ошибок не происходит.
Нипаанятно!

Какой таблицы, v_te? Точно IDENTITY(1,1)? Можешь Script Table->Create To сделать?

PS: и если уже взялся за извраты, то лучше SCOPE_IDENTITY, а то мало ли кто вклинится между вызовами

[sansa]

на ум приходит сделать выборку select max(id)

Принципиально - нет, база многопользовательская.

Какой таблицы, v_te?

нет, "tickets". v_te - вьюшка с таблицы ticket_events с триггером на вставку такого вида:
UPDATE ticket_events SET ... WHERE ...
INSERT INTO ticket_events () VALUES ()
Нужно для "версионности" таблицы эвентов (ну, как курсы валют), что бы потом можно было проследить порядок изменения статуса талона.

Точно IDENTITY(1,1)?

Точно, проверил в первую очередь, на всякий случай пересоздал таблицу.
Кстати, сейчас заметил, что и в ticket_events та же шляпа.

то лучше SCOPE_IDENTITY

Смотрел на нее, но не разобрался в майкрософтовских терминах. И вроде, как я понял IDENT_CURRENT - тот же SCOPE, только с фильтром по имени таблицы. Но попробую, спасибо.

и если уже взялся за извраты,

Обычная ситуация со вставкой в master-detail отношения. В нормальных СУБД влет решается генераторами. Если есть штатное решение для MS - с удовольствием выслушаю, так как таких таблиц у меня несколько.

ЗЫ. Можно, конечно, это перенести в контроллер, но в постгре это занимает 3 строки, и все работает, в MS - 3 строки, все работает, но с непонятным глюком, в контроллере мне это выйдет по 200 строк кода на каждое отношение.

[AlikForever]

Смотрел на нее, но не разобрался в майкрософтовских терминах. И вроде, как я понял IDENT_CURRENT - тот же SCOPE, только с фильтром по имени таблицы. Но попробую, спасибо.

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

Обычная ситуация со вставкой в master-detail отношения. В нормальных СУБД влет решается генераторами. Если есть штатное решение для MS - с удовольствием выслушаю, так как таких таблиц у меня несколько.

решается созданием отдельной таблички sequence, в которой для каждой таблички по имени счетчик лежит. Для получения-и-инкремента можно хранимку написать типо getNextID(table_name) (это если не через контроллер делать).

вот как-то так (стырил тока что в нете), оформить тока как функцию.

CREATE TABLE Sequence(Name VARCHAR(50) NOT NULL, ID INT NOT NULL DEFAULT(0))

--- тут вот CREATE FUNCTION
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
UPDATE Sequence WITH(HOLDLOCK) SET ID = ID + 1 WHERE Name = 'Table1'
SELECT ID FROM Sequence WHERE Name = 'Table1'
COMMIT TRAN

ЗЫ. Можно, конечно, это перенести в контроллер, но в постгре это занимает 3 строки, и все работает, в MS - 3 строки, все работает, но с непонятным глюком, в контроллере мне это выйдет по 200 строк кода на каждое отношение.

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

---------- Сообщение добавлено в 20:54 ---------- Предыдущее сообщение было в 20:50 ----------

PS: про триггеры вообще забудь как страшный сон

---------- Сообщение добавлено в 20:58 ---------- Предыдущее сообщение было в 20:54 ----------

Кстати, начиная с MS SQL 2011 говорят появились нормальные sequence, так что если можешь поставить его - то дерзай

[sansa]

можно хранимку написать типо getNextID(table_name)

Тут тоже конкуренция возможна, при одновременном запросе от двух транзакций.

PS: про триггеры вообще забудь как страшный сон

Ок, переделаю все на процедуры ))

автоинкремент где-то два раза вызывается

Это понятно, BOL так сразу и намекает.

Если дамп базы дашь - могу поискать.

Завтра скину, если тебе не лень )

[AlikForever]

Тут тоже конкуренция возможна, при одновременном запросе от двух транзакций.

да не, запись с именем таблицы до commit залочится, с этим все ок.

Завтра скину, если тебе не лень )

да, кидай - я думаю быстро разберусь Можешь попробовать тригер и вьюшку прибить сперва и попробовать )

[sansa]

запись с именем таблицы до commit залочится

MS все еще на блокировках? Уууу, как все запущено ) Я, конечно, слышал, что MS SQL "не айс", но все как-то не верил )

Ок, завтра перепишу логику на хранимках, и если останутся траблы, скину скриптик.
ЗЫ. У меня 2005 (контроллер заявляет поддержку только его). Ну, и еще он EXPRESS, так как баз нужно много, а ограничение на 4 гига данных для меня не является ограничением, максимум метров 20-30 будут.

[AlikForever]

MS все еще на блокировках? Уууу, как все запущено ) Я, конечно, слышал, что MS SQL "не айс", но все как-то не верил )

ЭЭЭ, а как ты себе по другому это представляешь?)) Когда две транзакции пытаются обновить одну запись - кто-то же должен подождать? (в смысле блокировка на запись)


---------- Сообщение добавлено в 00:09 ---------- Предыдущее сообщение было в 00:06 ----------

Ну, и еще он EXPRESS, так как баз нужно много, а ограничение на 4 гига данных для меня не является ограничением, максимум метров 20-30 будут.

Это даже не объемы))

PS: с MS SQL все более-менее норм, кстати, не знаю чего ты так категорично) Просто триггерами-шмигерами ее грузить не надо и индексы где нужно включать - в остальном все зависит от кривизны рук больше)

[sansa]

ЭЭЭ, а как ты себе по другому это представляешь?))

Не, я не дорос, но люди, версионность уже придумали )

не знаю чего ты так категорично)

Очень много вроде есть - но работает либо с ограничением, либо как с триггерами - лучше не использовать.
Реально полезное пока нашел только одно - простой инкрементальный бэкап.

[AlikForever]

Не, я не дорос, но люди, версионность уже придумали )

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

Очень много вроде есть - но работает либо с ограничением, либо как с триггерами - лучше не использовать.
Реально полезное пока нашел только одно - простой инкрементальный бэкап.

для твоих объемов данных у MS SQL нет проблем, есть мелкие неудобства скорее))

[sansa]

Переделал на процедурку - то же самое. дамп во вложении (переименовать в db_dump.7z и распаковать).

Интересует процедурка cmt. Вызов:
cmt 6, 1, 1
Она за раз создает по одной новой записи в таблицах tickets и ticket_events. Вызывать можно несколько раз с одними и теми же параметрами.

[sansa]

есть мелкие неудобства скорее))

MS SQL - мелкие неудобства???
Простой отказ от тригеров приводит к появлению кучи "копипаста" по процедурам, много одних и тех же действий в разных местах, что в скором будущем приведет к тому, что вносить изменения в БД будет сложнее, чем переписать с нуля.
А чего стоит непонятный запрет на использование инсертов в функциях?
А возврат табличных данных из процедуры? Во первых что бы эту возможность, нужно инет переыть (в BOL нету описания), так еще и о типизации возвращаемых значений можно забыть (что опять же на сопровождении сказывается).
А выполнить select из процедуры, возвращающей табличные данные? А транспонирование результата запроса?

Это еще не все, с чем я столкнулся за неполный месяц общения.

ЗЫ. Самые лучшие решение (исходя из моей практики) простые и, соответственно, красивые. При этом они еще и надежные выходят. А тут все на костылях и обертках получается.

[AlikForever]

Переделал на процедурку - то же самое. дамп во вложении (переименовать в db_dump.7z и распаковать).

Интересует процедурка cmt. Вызов:
cmt 6, 1, 1
Она за раз создает по одной новой записи в таблицах tickets и ticket_events. Вызывать можно несколько раз с одними и теми же параметрами.

У меня сработало нормально. за два раза создались tickets c id 64,65 и ticket_events - 74,75. Все ок

PS: и называй все сущности в единственном числе, вроде как принято так

---------- Сообщение добавлено в 17:12 ---------- Предыдущее сообщение было в 17:07 ----------

Может MDF файл пришли?

[sansa]

PS: и называй все сущности в единственном числе, вроде как принято так

У меня наименования пришли из Delphi. Там такая была была система (Strings, но StringList, Events).

У меня сработало нормально. за два раза создались tickets c id 64,65 и ticket_events - 74,75. Все ок

Ну, вот ) У меня перед отправкой - 61 и 63 и 71 и 73. После этого сделал дамп и отправил. И это не EXPRESS, это полный MSSQL.

Вот как к такому относится? )

---------- Сообщение добавлено в 18:14 ---------- Предыдущее сообщение было в 18:13 ----------

Может MDF файл пришли?

Админа БД у нету уже. Завтра попробую.

[AlikForever]

MS SQL - мелкие неудобства???
Простой отказ от тригеров приводит к появлению кучи "копипаста" по процедурам, много одних и тех же действий в разных местах, что в скором будущем приведет к тому, что вносить изменения в БД будет сложнее, чем переписать с нуля.
А чего стоит непонятный запрет на использование инсертов в функциях?
А возврат табличных данных из процедуры? Во первых что бы эту возможность, нужно инет переыть (в BOL нету описания), так еще и о типизации возвращаемых значений можно забыть (что опять же на сопровождении сказывается).
А выполнить select из процедуры, возвращающей табличные данные? А транспонирование результата запроса?

Это еще не все, с чем я столкнулся за неполный месяц общения.

ЗЫ. Самые лучшие решение (исходя из моей практики) простые и, соответственно, красивые. При этом они еще и надежные выходят. А тут все на костылях и обертках получается.

"простой отказ от триггеров" - тебя должно выворачивать уже при одном упоминании этого слова)) это не простой отказ)

PS: по поводу всего остального - когда у тебя будут таблицы по несколько десятков (сотен) миллионов записей, ты и про все остальные слова забудешь) Будешь только радоваться когда поиск в индексе отработал быстро И при этом содержание самого индекса не вырубает общую производительность в ноль


---------- Сообщение добавлено в 17:23 ---------- Предыдущее сообщение было в 17:18 ----------

У меня наименования пришли из Delphi. Там такая была была система (Strings, но StringList, Events).
---
Админа БД у нету уже. Завтра попробую.

Поставь у себя на компе хотя бы даже экспресс, и базу из скриптов своих же подними. Если будет все ок - покажи админу бидэ и спроси wtf

PS: ох уж этот дельфи

[sansa]

У тебя объемы большие, логика простая, у меня объемы маленькие, логика сложная. На клиента ее вынести не могу и не хочу - принципиально неверно.
Поэтому и бухтю ) Я же даже не с ораклом сравниваю, с опенсорсом.
Вот, кстати, как без триггеров решить проблему (сидю и думаю):
В таблице допускается множество записей с одинаковым значением поля "ID" и значением поля "ST" <> 3 (допустим). Если "ST" = 3, то такая запись для указанного "ID" должна быть только одна.
Еще, похожая: тоже, только ("CL" is null) и ("CL" is not null)
У постгре - это разделяемые индексы. Тут такого не нашел, думал триггер повесить.

[sansa]

по несколько десятков (сотен) миллионов записей, ты и про все остальные слова забудешь)

Кстати, вспомнил, как года 3 назад, когда заморачивались с GIS, вопрос быстрого поиска в огромных объемах очень красиво решился кластеризацией таблиц (штатная фишка постгре и оракла) по основным критериям поиска.

[AlikForever]

У тебя объемы большие, логика простая, у меня объемы маленькие, логика сложная. На клиента ее вынести не могу и не хочу - принципиально неверно.
Поэтому и бухтю ) Я же даже не с ораклом сравниваю, с опенсорсом.
Вот, кстати, как без триггеров решить проблему (сидю и думаю):
В таблице допускается множество записей с одинаковым значением поля "ID" и значением поля "ST" <> 3 (допустим). Если "ST" = 3, то такая запись для указанного "ID" должна быть только одна.
Еще, похожая: тоже, только ("CL" is null) и ("CL" is not null)
У постгре - это разделяемые индексы. Тут такого не нашел, думал триггер повесить.

Никогда не решал вопросы бизнес-логики на уровне базы, вот никогда База это просто структура данных с какими-то отношениями, не надо ее перегружать всяким мусором)

---------- Сообщение добавлено в 21:10 ---------- Предыдущее сообщение было в 21:04 ----------

Кстати, вспомнил, как года 3 назад, когда заморачивались с GIS, вопрос быстрого поиска в огромных объемах очень красиво решился кластеризацией таблиц (штатная фишка постгре и оракла) по основным критериям поиска.

Кластеризация это просто файловое хранилище по кластеру раскидывают? ну это вопрос больше к админам..

[sansa]

Никогда не решал вопросы бизнес-логики на уровне базы, вот никогда

Ну, у каждого свои недостатки ))

Кластеризация это просто файловое хранилище по кластеру раскидывают?

не, боунсеры - это отдельная тема. Тут примерно так:
Есть у тебя 100 сотрудников, у каждого тыщамильенов записей. И тебе очень часто нужны данные по одному или нескольким сотрудникам. Если грубо, то кроме основной таблицы, создаются 100 таблиц (для каждого сотрудника). И тогда, если нам нужно выбрать все документы какого-либо сотрудника, нет необходимости перывать все 100 тыщ мильенов записей, нужно обратиться к таблице этого сотрудника, и пересмотреть только одну тыщу мильенов (на самом деле меньше, принимая во внимание индексы). Т.е. скорость поиска увеличивается на 2 порядка (примерно).