дольше ли будет запрос(MSSQL)?

← →
Аббат Пиккола (2012-12-05 13:49) [40]

Допустим у меня есть сетка с множественным выбором. Пользователь может отметить строки, которые ему нравятся. Я просто фантазирую. И допустим я ничего не знаю о том, что текст SQL-запроса имеет реальные ограничения на длину. И вовсе не 4 гигабайт, как некоторые могут подумать. А гораздо меньше. И я, не долго думая, хочу запомнить отмеченные пользователем строки в виде перечисления их ID и применить в каком-то SQL-запросе. Ничего не зная о подобных ограничениях, так как о них мало где пишут. Пользователь же зачем-то решил для построения своего отчета (который он просил для "выбранных нескольких строк") отметить все записи в сетке, сняв все прочие фильтрации, а их там были десятки тысяч...

Ну например.

← →
наивный Талейран (2012-12-05 13:52) [41]

> Аббат Пиккола (05.12.12 13:49) [40]

> Пользователь же зачем-то решил ... отметить все записи в сетке, сняв все прочие фильтрации

голосую за возрождение святой инквизиции

← →
знайка (2012-12-05 13:56) [42]

Надо пользоватся средствами сервера, раз ух заплатили за их, а не запросы генерить. :)

← →
Аббат Пиккола (2012-12-05 13:57) [43]

2 наивный Талейран (05.12.12 13:52) [41]

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

← →
наивный Талейран (2012-12-05 14:02) [44]

> Аббат Пиккола (05.12.12 13:57) [43]

поддерживаю

← →
MsGuns © (2012-12-05 14:12) [45]

>знайка (05.12.12 13:56) [42]
>Надо пользоватся средствами сервера, раз ух заплатили за их, а не запросы >генерить. :)

Вот и я об этом же ([6]). Но ТС тот пост просто проигнорил :)

← →
O'ShinW © (2012-12-05 14:16) [46]

> MsGuns © (05.12.12 14:12) [45]

нет,
ТС читает все.

← →
Аббат Пиккола (2012-12-05 14:19) [47]

Раз уж в MS SQL принято создавать временные таблицы, то действительно, почему бы ими не воспользоваться? Если у Вас MS SQL, конечно.

← →
MsGuns © (2012-12-05 14:21) [48]

+
По сути топика вопрос. Откуда на клиенте берется 100500 значений, вставляемых в суперпупергиперзапрос ?
Есть три ответа:

1) Значения берутся из некоего набор данных, полученного на клиенте в результате выполнения опять же запроса.
Вопрос к разработчику: отчего не взять в качестве where/join on вот этот самый запрос, избежав опять же непонятных "ручных" суперзапросов ?

2) Значения вводятся непосредственно юзверем.
Вопрос к разработчику: каким образом юзверь сможет ввести 100500 значений ? А если их (значений) на три порядка меньше, то о чем тогда базар ?

3) Значения извлекаются из внешних источников (сторонние базы например).
Вопрос к разработчику: Почему не избрать путь промежуточной таблицы (6), ИМХО, наиболее оптимальный в данном случае ?

← →
Аббат Пиккола (2012-12-05 14:22) [49]

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

← →
MsGuns © (2012-12-05 14:22) [50]

>Аббат Пиккола (05.12.12 14:19) [47]

Временные таблицы умеет создавать не только мс скл

← →
MsGuns © (2012-12-05 14:26) [51]

Скажу больше - сейчас наверное не просто найти промсервер скл, не знающий временные таблицы

← →
Аббат Пиккола (2012-12-05 14:31) [52]

2 MsGuns © (05.12.12 14:26) [51]

Я на InterBase вполне обхожусь без них.
Правда у меня много лет было одно преимущество - возможность порождать искусственные наборы с помощью ХП (оператор SUSPEND). Я слышал, что в последних версиях MS SQL тоже появилась такая возможность.

← →
Аббат Пиккола (2012-12-05 14:32) [53]

А вообще это неважно. Хотелось бы услышать ответ на MsGuns © (05.12.12 14:21) [48]

← →
знайка (2012-12-05 14:34) [54]

Да и не только временные таблицы, по месту надо смотреть что лучше, может юзердефайнтип, может xml может еще чего...
Вот запросы генерить это прошлый век.

← →
O'ShinW © (2012-12-05 14:35) [55]

> MsGuns © (05.12.12 14:21) [48]

вы таки будете смеяться, но запросу > 10 лет и его реально правили так, что добавляли новые id непосредственно в текст.
т.е. раньше там, я так подозреваю, было пару значений. Потом добавляли и добавляли. За десять лет имеем экран! айдишков в перечислении.
Мне "выпало счастье" его поправить в очередной раз.
Решил безобразие остановить.

Кстати, хотел создать таблицу, и даже не временную, а постоянную, и задокументировать ее добавление, как таблу под отчетность. С написанием интерфейса аля проект1.dpr, что бы манагеры сами решали какие группы туда добавить.

Но, имхо, красиво выходит, если искать лайком.
выдрал все id и запросил. В поле Name у всех есть слово "физические", точнее, "изически"

зы
Кстати, Серега, тебя я всегда внимательно читаю

← →
MsGuns © (2012-12-05 14:43) [56]

>O"ShinW © (05.12.12 14:35) [55]
>За десять лет имеем экран! айдишков в перечислении.

Судя по этой фразе, надо срочно весь проект "в печку !" (с)

← →
Аббат Пиккола (2012-12-05 14:46) [57]

В поле Name у всех есть слово "физические", точнее, "изически"

Это какое-то случайное совпадение?

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

← →
MsGuns © (2012-12-05 14:47) [58]

Удалено модератором

← →
O'ShinW © (2012-12-05 15:00) [59]

> Аббат Пиккола (05.12.12 14:46) [57]

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

> MsGuns © (05.12.12 14:47) [58]

Постепенно переводим, последние 2 года. На уракл, где совсем по-другому все будет. А пока приходится поддерживать недобитки.
Возможно, еще с год :)

← →
знайка (2012-12-05 15:02) [60]

> Но, имхо, красиво выходит, если искать лайком.
ну вот, а тут копья ломают :)

← →
Аббат Пиккола (2012-12-05 15:03) [61]

2 MsGuns © (05.12.12 14:47) [58]

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

← →
Аббат Пиккола (2012-12-05 15:07) [62]

Кто сказал, что солнечные батареи это повод сразу отказываться от кизяков? Я понимаю, что мы тут страна богатая... Ресурсами людскими и прочими. А вот бедные непальцы полагают иначе и экономят на всем.

← →
Дмитрий С © (2012-12-05 15:10) [63]

Удалено модератором

← →
Кука съела ник (2012-12-05 15:42) [64]

наивный Талейран (05.12.12 12:13) [30]

> там только синтаксически объединение

В одном случае обращение к одной таблице, в другом к двум.

Термин "синтаксически объединение" применительно к теории баз данных мне не знаком

← →
наивный Талейран (2012-12-05 16:01) [65]

> Кука съела ник (05.12.12 15:42) [64]

> В одном случае обращение к одной таблице, в другом к двум.

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

← →
Аббат Пиккола (2012-12-05 16:09) [66]

Если так много сомнений, может вообще лучше ничего не трогать.

Я бы так долго не думал на эту тему, ей богу.
Значит там еще есть какой-то подводный камень...
Например, может быть очень хорошо для налогообложения, что какие-то ID находятся в специальном списке, который спрятан глубоко в недрах SQL-запросов.
А не в лежит у всех на виду в виде признака "Фирма-Поганка".

← →
Аббат Пиккола (2012-12-05 16:26) [67]

Благими намерениями можно испортить многое. Приходит вот так программист. Нормальный вроде бы человек. Видит, ряд фирм "ООО Вася" через один пробел, а часть, например, "ООО Сигизмунд." - через два пробела. Да еще и с точкой в конце. И думает, а не отформатировать ли мне все эти фирмы так, чтобы было красиво...
А потом прибегает бухгалтер в ужасе "Что Вы наделали!!!!"...
Ситуация придуманная, но такое вполне возможно.

← →
Ваще имя (2012-12-05 16:35) [68]

А меня раздражает нарицательный ID

> Аббат Пиккола (05.12.12 16:26) [67]

Возможно, конечно.
И примерно такое и бывало. Устаканилось уже.

Не, все равно надо как то менять. Такое перечисление ни к чему.
А когда запросил по id и по имени,
выяснилось, что некоторые группы, например, уже не актуальные.
т.е. ничего страшного, что они там есть, но могло бы их и не быть.
т.е. актуальные группы именуются по правилу,
остальные же просто пустые, или их листья мертвые.
Если продолжать добавлять группы по правилу - они автоматически будут попадать. т.е. запрос больше не надо переписывать.

Хотя.. по идее, можно еще одну группу ввести. (ну или таблицу эту)

> А меня раздражает нарицательный ID

чаще всего - меня тоже :)

Но если он например, ни к чему?
т.е. пусть таблица будет такая, где он не нужен.
Как истинный idот, я все равно введу его :)
Пусть будет. Сейчас не нужен, но неизвестно что потребуется завтра.

← →
Кука съела ник (2012-12-05 16:49) [71]

наивный Талейран (05.12.12 16:01) [65]

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

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

← →
Ваще имя (2012-12-05 17:09) [72]

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

Из этого следует, что синтетический ключ можно ввести завтра с тем же успехом

> Из этого следует, что синтетический ключ можно ввести завтра
> с тем же успехом

...и переписать все запросы.

← →
наивный Талейран (2012-12-05 17:31) [74]

> Кука съела ник (05.12.12 16:49) [71]

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

Во второй таблице 50 записей, ща проверим:

PointOfTruth:

if (TimeSelectFromTwoTable - TimeSelectFromOneTable) < 0.0000000000001 then
ShowMessage("Зануда")
else goto PointOfTruth;

← →
Ваще имя (2012-12-05 17:49) [75]

> goto

!!!

дольше ли будет запрос(MSSQL)? Найти похожие ветки