Здравствуйте!
Народ, очень интересно знать появилась ли поддержка типа "массив" в новой версии T-SQL 2008 ?
если да, можно ли теперь передавать переменные этого типа(или хотя бы table) в хранимки и т.д.

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

Расскажите пожалуйста, кто в курсе дела.

Огромное спасибо!

Аноним 27 пишет:
> Народ, очень интересно знать появилась ли поддержка типа "массив" в
> новой версии T-SQL 2008 ?

В реляционной СУБД тип "массив" не нужен и даже вреден. В реляционных
СУБД есть таблицы, ими и надо пользоваться.

MZ>В реляционной СУБД тип "массив" не нужен и даже вреден. В реляционных
MZ>СУБД есть таблицы, ими и надо пользоваться.

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

Здравствуйте, MasterZiv, Вы писали:

MZ>В реляционной СУБД тип "массив" не нужен и даже вреден. В реляционных
MZ>СУБД есть таблицы, ими и надо пользоваться.
В релционных СУБД — да, а при взаимодействии оных с клиентским приложением — нет.
Не надо путать теплое с мягким.

Здравствуйте, Аноним, Вы писали:

А>не стоит ущербность t-sql проецировать на все рсубд.
Не стоит вообще поднимать тему ущербности какого-либо sql, равно как и тему проекции на все рсубд, не разобравшись что такое рсубд.

А> кто сказал, что плоские, двумерные таблицы наилучший способ передавать сложные структуры ?
Кто здесь вообще сказал хоть слово про "наилучший способ" передавать?

А> было бы логично, чтоб клиент передавал бы многомерный массив,
Куда передавал и о чьей логике речь?

A> а не табличные переменые которые завязаны на конекцию
В чем проблема завязки клиентских данных на конкретное соединение с БД?

A> и будут глючить при появлении понятия автономных транзакций.
Автономная транзакция — вообще оксюморон. Это если разобраться с рсубд.

IB>Кто здесь вообще сказал хоть слово про "наилучший способ" передавать?
MasterZiv, заявив что нужно пользоватся табличками например ...

А>> было бы логично, чтоб клиент передавал бы многомерный массив,
IB>Куда передавал и о чьей логике речь?
заниматся таким: http://www.sql.ru/articles/mssql/03060701ArraysAndListsInSQLServer.shtml
не логично, логично передавать массив.

A>> а не табличные переменые которые завязаны на конекцию
IB>В чем проблема завязки клиентских данных на конкретное соединение с БД?
в tempdb, когда сиквел доростет то того чтоб запустить в одной конекции несколько процедур параллельно (автономные транзакции) вылезет большая проблема.

Здравствуйте, <Аноним>, Вы писали:

А>MasterZiv, заявив что нужно пользоватся табличками например ...
Еще раз, где хоть слово про наилучший способ передачи?

А>не логично, логично передавать массив.
И чем, по-твоему, отличается таблица от массива?

А>в tempdb,
Причем тут tempdb?

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте!
А>Народ, очень интересно знать появилась ли поддержка типа "массив" в новой версии T-SQL 2008 ?
А>если да, можно ли теперь передавать переменные этого типа(или хотя бы table) в хранимки и т.д.

А>Огромное спасибо!

В 2008 будут табличные параметры.

А>>MasterZiv, заявив что нужно пользоватся табличками например ...
IB>Еще раз, где хоть слово про наилучший способ передачи?
попробуйте перечитать топик

А>>не логично, логично передавать массив.
IB>И чем, по-твоему, отличается таблица от массива?
плоскостью и местом хранения.

А>>в tempdb,
IB>Причем тут tempdb?

A table variable is not a memory-only structure. Because a table variable might hold more data than can fit in memory, it has to have a place on disk to store data. Table variables are created in the tempdb database similar to temporary tables.
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977


А>> когда сиквел доростет то того чтоб запустить в одной конекции несколько процедур параллельно (автономные транзакции) вылезет большая проблема.
IB>Во-первых, сиквел давно уже это умеет, во-вторых, это ни каким боком не "автономные" транзакции и, наконец, в третих, никаких проблем это не создает, ни в tempdb, ни где-либо еще.

во первых как давно, во вторых кто сказал, в третих как проверялось ?

Здравствуйте, <Аноним>, Вы писали:

А>попробуйте перечитать топик
Ок, где хоть слово, про наилучший способ передачи, кроме твоих? (попробуй внимательно перечитать хотя бы мое предложение)

А>плоскостью и местом хранения.
Какой плоскостью и каким местом?

А>A table variable is not a memory-only structure.
И?

А>во первых как давно,
Лет несколько.

А> во вторых кто сказал,
Ты хорошо понимаешь что такое "автономная" транзакция? Можешь определение привести?

А> в третих как проверялось ?
На практике.

А>>попробуйте перечитать топик
IB>Ок, где хоть слово, про наилучший способ передачи, кроме твоих? (попробуй внимательно перечитать хотя бы мое предложение)

перечитал — нашел.

А>>плоскостью и местом хранения.
IB>Какой плоскостью и каким местом?

вот тем, куда вы сейчас смотрите.

А>>во первых как давно,
IB>Лет несколько.

сумневаюсь я.

А>> во вторых кто сказал,
IB>Ты хорошо понимаешь что такое "автономная" транзакция? Можешь определение привести?

да, хорошо, да могу.

А>> в третих как проверялось ?
IB>На практике.

вам показалось, вы не то проверяли.

Аноним 866 пишет:
> MZ>В реляционной СУБД тип "массив" не нужен и даже вреден. В реляционных
> MZ>СУБД есть таблицы, ими и надо пользоваться.
>
> не стоит ущербность t-sql проецировать на все рсубд. кто сказал, что
> плоские, двумерные таблицы наилучший способ передавать сложные структуры

В реляционной СУБД других вариантов у нас нет. Тебе не нравится — не используй.

> не стоит ущербность t-sql проецировать на все рсубд. кто сказал, что

Для реляционной СУБД TSQL — замечательный язык программирования.
Опять-таки, не нравится — не используй.

Здравствуйте, <Аноним>, Вы писали:

А>перечитал — нашел.
Так где?

А>вот тем, куда вы сейчас смотрите.
Так скажешь для чего тебе нужен массив в реляционке или не можешь?

А>сумневаюсь я.
Не сомневайся.

А>да, хорошо, да могу.
Ну так приведи.

А>вам показалось, вы не то проверяли.
Боюсь, ты просто не очень хорошо разбираешься данном вопросе.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, <Аноним>, Вы писали:

А>>перечитал — нашел.
IB>Так где?

А>>вот тем, куда вы сейчас смотрите.
IB>Так скажешь для чего тебе нужен массив в реляционке или не можешь?

А>>сумневаюсь я.
IB>Не сомневайся.

А>>да, хорошо, да могу.
IB>Ну так приведи.

А>>вам показалось, вы не то проверяли.
IB>Боюсь, ты просто не очень хорошо разбираешься данном вопросе.

Дмитрич...не бей только его

А>>перечитал — нашел.
IB>Так где?
все тамже

А>>вот тем, куда вы сейчас смотрите.
IB>Так скажешь для чего тебе нужен массив в реляционке или не можешь?
читайте топик, там все есть, не люблю повторятся.

А>>сумневаюсь я.
IB>Не сомневайся.
вспоминая ваши откровения по поводу оракловых блокировок у читающих транзакций позволю себе усомнится

А>>да, хорошо, да могу.
IB>Ну так приведи.
rtfm oracle docs

А>>вам показалось, вы не то проверяли.
IB>Боюсь, ты просто не очень хорошо разбираешься данном вопросе.
очень вероятно, но наверника лучшем чем некоторые ...

Здравствуйте, <Аноним>, Вы писали:

А>все тамже
То есть, нету..

А>читайте топик, там все есть, не люблю повторятся.
Зачем повторяться, хоть раз скажи.

А>вспоминая ваши откровения по поводу оракловых блокировок у читающих транзакций позволю себе усомнится
В оракле усомниться? Давно пора.

А>rtfm oracle docs
То есть, как и ожидалось, сформулировать сам ты не можешь.

А>очень вероятно, но наверника лучшем чем некоторые ...
Сдается мне, что этих некоторых исчезающе мало.

Итак, в синем углу ринга — Иван Бодягин, неоднократный MVP, бессменный Top0 форума Базы Данных на RSDN, автор восьми статей и восьмидесяти девяти избранных сообщений.
В красном углу ринга — Аноним.

Ставки?

ладно еще раз попробую перевести торик в конструктивное русло.
массивы мне нужны чтоб
1. передавать вложенные структуры.
2. это должна быть стуктура в памяти, как и все переменные, чтоб избежать конкуренции и/о в tempdb в котором и так чего только нет — от сортировок до юлозания тригеров и версионности.
3. это должна быть стуктура в памяти, чтоб избежать чудовищного расхода ресурсов: писания логов, перекомпиляция процедур, сбор статистики для оптимизатора и т.п.
4. ну и наконец область видимости — таблица должна быть видима во всех процедурах, а поведение массива должно совпадать с поведением остальных переменных.

Дано:
запрос вида
select ID,что-то там
from таблица
where ID in (некоторое количество чисел)

Надо:

дать приложению возможность вызывать
хранимую процедуру с параметром, в котором указывать "некоторое количество чисел"

Ограничение:

Приложение не умеет работать с xml настройкой над SQL и IIS.

Решение:

1. Собирать запрос ручками и не использовать хранимку.
2. Перекомпилируемая хранимка
3. Привод чисел к строке.


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

4. Извращение с временной/промежуточной таблицей, которую приложение должно заполнять (sic!) циклом.

Недостаток — большое кол-во транзакций и распухание лога.

Вроде больше способ не знаю.

Мечты о человеческом счастье:

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

В начале топика Аноним спрашивал (на сколько я понял), появилась ли подобная возможность
в SQL 2008.

[off]Нафига уважаемые люди скатываются до взаимных оскорблений вместо просто ответа на вопрос, который требует только двух вариантов (да/нет)[/off]

Здравствуйте, <Аноним>, Вы писали:

А>1. передавать вложенные структуры.
Вложенные во что? Какой размерности должен быть этот массив?

А>2. это должна быть стуктура в памяти, как и все переменные, чтоб избежать конкуренции и/о в tempdb в котором и так чего только нет — от сортировок до юлозания тригеров и версионности.
Ты предлагаешь весь тот мусор, который хранится в переменных, держать в памяти в ущерб другим данным? Оригинально.
Эта структура никому ничего не должна, она должна хранится там где удобно сиквелу. Никакой лишней конкуренции это не вызовет, tmpdb специально предназначена для таких вещей и разрабатывалась с учетом именно такой нагрузки.

А>3. это должна быть стуктура в памяти, чтоб избежать чудовищного расхода ресурсов: писания логов, перекомпиляция процедур, сбор статистики для оптимизатора и т.п.
Временные структуры, типа VSH, в лог не пишутся, перекомпиляция процедур тут вообще не причем, равно как и статистика для оптимизатора.
Не смотря на то, что tempdb выглядит как обычная БД — это совершенно отдельная структура, оптимизированная под работу в качестве временного хранилища служебных данных.
Если для целостности данных необходимо, чтобы велся лог и статистика, значит они будут там вестись, если такой необходимости нет — то не будут. Не считай себя умнее разработчиков сиквела.

А>4. ну и наконец область видимости — таблица должна быть видима во всех процедурах,
Таблица, опять-таки, никому ничего не должна. Область видимости временных таблиц и табличных переменных в сиквеле ограничена процедурой или подключением. И это правильно.

А> а поведение массива должно совпадать с поведением остальных переменных.
Поведение табличных переменных совпадает с поведением остальных переменных.