Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Мимопроходящий
ну а ныне, к примеру, стоимость = количество * цена,
если любой из операндов NULL, то результат NULL, вполне логичен.

Он логичен математически. Но нелогичен и неудобен по бизнесу, с точки зрения решения практических задач.

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

Мимопроходящий
ты предлагаешь генерить exception для таких случаёв?

Да. Полагаю, так будет лучше.
16 ноя 06, 18:18    [3411464]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32893

Привет, softwarer!
Ты пишешь:

softwarer
Мимопроходящий
ты предлагаешь генерить exception для таких случаёв?

s> Да. Полагаю, так будет лучше.
в таком случае, в селекте ты не увидишь
тех данных, которые в кортеже следуют "после"
строки, генерирующей exception.
это хорошо, или плохо?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

16 ноя 06, 18:21    [3411475]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
Это только синтаксис, за которым скрывается мощный промежуточный слой, доступный клиентам фактически только через "родной" API.

Нда. Признаться не ожидал, что Вы докатитесь до прямой лжи. Я лично сказал Вам, что этот слой доступен через ODBC. Вы легко могли бы выяснить, что он доступен через JDBC. Насчет ADO - не в курсе, наверное доступен, но лень выяснять. Итого, доступность в не менее чем 2/3 распространенных стандартов Вы назвали "только через родной API".

Поздравляю Вас, гражданин.
16 ноя 06, 18:21    [3411477]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
Сколь я помню ту статью, никакого дополнительного геморроя при этом нет. Cерверная процедура остается неизменной, в ODBC результат возвращается так же, как вернулся бы из аналогичной MSSQL-процедуры и выбирается тем же клиентским кодом.
Если Вы говорите о возврате только одного рекордсета, то нет проблем. Но Вы сами заикнулись о множественных результатах, получаемых через именованные параметры. Вот мне и стало интересно, как именно это эмулируется через ODBC. Будьте любезны, ссылочку на статью.
softwarer
ChA
Полагаю в Oracle тоже найдутся подобные казусы, но мы о них разумеется, говорить не будем.
Наверное, найдутся. Говорите, с интересом послушаю. Вон, председатель тоже был уверен в наличии казуса.
Забавно, но мне казалось, что это Вы могли бы рассказать, я могу рассказать только по MSSQL. Итак, в Oracle того, что Вы называете казусом, не бывает, я Вас правильно понял ?
Повторюсь, с председателем разбирайтесь сами, я не собираюсь отвечать за то, что сказали другие.
softwarer
Слухи же Вы легко можете развеять, если приведете внушительный список распространенного прикладного ПО, использующего ODBC как единственный либо основной интерфейс взаимодействия с БД.
Практические любое, которое вынужденно работать с гетерогенными источниками. В частности, практически вся линейка продуктов Office.
softwarer
Общепринятых стандартов в RDBMS нет.
А я-то удивляюсь, как это из MSSQL можно получить данные из Oracle и наоборот.
softwarer
Стоп. Курсоры или рекордсеты? Поясню: в описанном механизме Oracle я могу один и тот же курсор и использовать на сервере, и передать на клиента. То есть если есть хранимка, возвращающая выборку, я могу использовать эту выборку и на сервере, и на клиенте. Сколь я понимаю в MSSQL, тот явный курсор, который можно передать, и тот неявный рекордсет, который едет на клиента - разные вещи, "одной процедуры для обоих применений" сделать не удастся. Или я заблуждаюсь?
В данном случае, не совсем. В MSSQL есть механизм передачи данных через именованный параметр, но только курсоров в смысле ANSI. Передача в виде параметра(ов) того, что Вы называете рекордсетами, в MSSQL отсутствует, хотя иногда и может быть сэмулирована. А процедура для возврата данных в вызывающую процедуру или клиенту может быть одна и та же, просто в вызывающей процедуре придется делать возврат рекордсета во временную таблицу или через OPENQUERY, хотя в случае множественных результатов могут быть проблемы.
softwarer
А кто Вам сказал, что я жду ответа от Вас?
Еще раз, почему тогда Вы задаете вопрос мне ? Я не прошу Вас отвечать за слова других ораклоидов, поэтому избавьте и меня от этого.
softwarer
Я лично сказал Вам, что этот слой доступен через ODBC.
С нетерпением жду ссылку на статью, где иллюстрируется работа с множеством именованных параметров типа рекордсет через ODBC.
16 ноя 06, 20:10    [3411950]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
solo28
Member

Откуда:
Сообщений: 114
Саш [softwarer], наверно непрофильный трид, но но подмывает спросить.
какие компоненты доступа к oraclе ты бы мог порекомендовать на win32 платформе ?
16 ноя 06, 20:38    [3412032]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Мимопроходящий
в таком случае, в селекте ты не увидишь
тех данных, которые в кортеже следуют "после"
строки, генерирующей exception.
это хорошо, или плохо?

Ээ... это где сервер так себя ведет?

Я как-то привык к тому, что получаю exception вместо выборки, если в ходе выполнения была ошибка. "Остановиться на ошибочной строке и вернуть половинчатый результат" - имхо неверная реакция в любом случае, null там или допустим деление на ноль.
17 ноя 06, 00:58    [3412446]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
Если Вы говорите о возврате только одного рекордсета, то нет проблем. Но Вы сами заикнулись о множественных результатах, получаемых через именованные параметры. Вот мне и стало интересно, как именно это эмулируется через ODBC. Будьте любезны, ссылочку на статью.

Первое, что нашел - http://dtemplatelib.sourceforge.net/OracleResultSets.htm Позволю себе небольшую цитату оттуда:

первая попавшаяся статья
* This program:

* Creates an ODBC connection to the database.
* Creates a Packaged Procedure containing two result sets.
* Executes the procedure and retrieves the data from both result sets.
* Displays the data to the user.
* Deletes the package then logs the user out of the database.

Хватит?

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

- Oracle возвращает выборки через именованные параметры
- возвращаемые через ref cursor выборки доступны при работе через ODBC.

ChA
Забавно, но мне казалось, что это Вы могли бы рассказать, я могу рассказать только по MSSQL. Итак, в Oracle того, что Вы называете казусом, не бывает, я Вас правильно понял ?

Право, не могу судить, что я по Вашему мнению называю казусом - в наш топик этот термин ввели.

Возможно, и мог бы что-то рассказать, но в том контексте, в котором развивается наша беседа, не вижу смысла. Чтобы создать у Вас верное впечатление - мои претензии к Oracle относятся к категории "жемчуг мелок".

ChA
Практические любое, которое вынужденно работать с гетерогенными источниками. В частности, практически вся линейка продуктов Office.

Итак, Office - принято. Правда, работа с БД - мягко говоря второстепенная часть его функционала, а в единственном БД-продукте - Access - ODBC основным протоколом вроде бы не является.

Any more?

ChA
softwarer
Общепринятых стандартов в RDBMS нет.
А я-то удивляюсь, как это из MSSQL можно получить данные из Oracle и наоборот.

Например, из MSSQL в Oracle лучше всего через MS SQL Server Transparent Gateway. Можно через ODBC, но это только если нужно "дешево и сердито". В обратном направлении качать не требовалось, не могу судить.

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

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

ChA
Еще раз, почему тогда Вы задаете вопрос мне ? Я не прошу Вас отвечать за слова других ораклоидов, поэтому избавьте и меня от этого.

Еще раз: я не задавал Вам вопрос. Если внимательно посмотрите сказанное, никакого вопросительного знака в той фразе не обнаружите.

Я подвел резюме различий, и в нем в том числе сослался на заданный мной вопрос, имея в виду его тему как одно из отличий.

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

Надеюсь, дождались.
17 ноя 06, 01:30    [3412480]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
solo28
Саш [softwarer], наверно непрофильный трид, но но подмывает спросить.
какие компоненты доступа к oraclе ты бы мог порекомендовать на win32 платформе ?

Лично я использую ODAC, местами доработанный под мои требования, и уходить с него не планирую. Если хочется из бесплатных, я бы в первую очередь посмотрел на AnyDAC от Дмитрия Арефьева; я его не смотрел за ненадобностью, но человек действительно грамотный и работает на совесть, результат должен быть хорош.
17 ноя 06, 01:34    [3412483]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Изопропил
Member

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

Например, из MSSQL в Oracle лучше всего через MS SQL Server Transparent Gateway. Можно через ODBC, но это только если нужно "дешево и сердито". В обратном направлении качать не требовалось, не могу судить.


Обратно - OLEDB под видом Linked Server,DTS ,OPENQUERY

автор
Итак, Office - принято. Правда, работа с БД - мягко говоря второстепенная часть его функционала, а в единственном БД-продукте - Access - ODBC основным протоколом вроде бы не является.

В новом офисе - добавлен OLEDB . В новом Excel работа с БД ,имхо, уже не второстепенная часть
17 ноя 06, 01:59    [3412502]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
Первое, что нашел - http://dtemplatelib.sourceforge.net/OracleResultSets.htm
И что Вы этим примером хотели показать ? Что данные из именованных параметров-рекордсетов считываются точно также, как если бы они считывались из аналогичной процедуры в MSSQL, т.е., последовательно ? Так мне не это было интересно, даже не вызывало сомнений, что это возможно.
softwarer
Кстати, чтобы уменьшить Вам возможность выкручиваться, сразу потребую уточнить Ваше утверждение. Я не делал утверждения в таком виде, в каком Вы его написали. Я сделал два отдельных утверждения:

- Oracle возвращает выборки через именованные параметры
- возвращаемые через ref cursor выборки доступны при работе через ODBC.
Хммм. Вы сделали утверждение
softwarer
"Нормально" - это возвращать сколько угодно выборок каждую через свой именованный out параметр
, на что получили ответ
ChA
Но этот механизм будет работать только через OCI, но не через ODBC, разве не так ?
. На что получаю
softwarer
Нет, не так. Точнее, я не имею личного опыта - не вижу никакого смысла использовать ODBC - но кого-то из спрашиваюших лично посылал в статью, где расписывалось, как использовать эту фичу через ODBC.
Я выражаю сомнение, что все так просто
ChA
реализация этой фичи даже если и возможна через ODBC, то сопровождается неоправданным геморроем в духе "мы это, конечно, сделать можем, но лучше не надо".
, но получаю
softwarer
Cерверная процедура остается неизменной, в ODBC результат возвращается так же, как вернулся бы из аналогичной MSSQL-процедуры и выбирается тем же клиентским кодом.
О как. И получаю завершающий удар
softwarer
Признаться не ожидал, что Вы докатитесь до прямой лжи. Я лично сказал Вам, что этот слой доступен через ODBC.
в ответ на
ChA
softwarer
по сравнению с MSSQL, в Oracle для записи того же требуется одна лишняя строка (open for select вместо просто select). Этим мы покупаем именованные параметры-рекордсеты и возможность легко крутить выборки так, как нам удобно, в частности передавать их между подпрограммами и использовать на сервере.
Это только синтаксис, за которым скрывается мощный промежуточный слой, доступный клиентам фактически только через "родной" API.
. И в качестве доказательства вы подсовываете код, в котором все именованные рекордсеты из Oracle идут через ODBC точно также, как и аналогичные из MSSQL, то бишь - "гуськом". Ну и где тут
software
именованные параметры-рекордсеты и возможность легко крутить выборки так, как нам удобно
, доступные через ODBC ? И кто после этого выкручивается ? Впрочем, этот вопрос уже становится риторическим.

softwarer
ChA
softwarer
Общепринятых стандартов в RDBMS нет.
А я-то удивляюсь, как это из MSSQL можно получить данные из Oracle и наоборот.

Например, из MSSQL в Oracle лучше всего через MS SQL Server Transparent Gateway. Можно через ODBC, но это только если нужно "дешево и сердито". В обратном направлении качать не требовалось, не могу судить.
Замечательно, и через что работает MS SQL Server Transparent Gateway ? Если верить google, то не через ODBC или OLEDB, а через некий native API MSSQL. Последнее, что осталось - DBLibrary, но
BOL
The DB-Library API has not been enhanced beyond the level of SQL Server version 6.5. All DB-Library applications can work with SQL Server 2000, but only as 6.5 level clients. Features introduced in SQL Server 2000 and SQL Server version 7.0 are not supported for DB-Library applications.
При этом он почему-то лучше. По каким критериям ? Проводилось тестирование, которое показало безусловное преимущество MS SQL Server Transparent Gateway перед всеми другими вариантами или просто так написано в документации ? Я не ошибусь, если предположу, что упомянутый выше Gateway продается отдельно ?

Еще один риторический вопрос. Если нет общепринятых стандартов, то нахрена, собственно, Oracle вообще поддерживает работу с ODBC, ADO, OLEDB, а также добавляет в свою диалект SQL новые возможности, декларируемые ANSI, например, те же JOIN, которые вам не нравятся ?

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

Это решение понятно, но ведет к существенным накладным расходам, соответственно в исходной фразе я не имел его в виду. Понятно, что через временные таблицы можно сделать практически все что угодно.
И где там "существенные накладные расходы" ? Я готов согласиться, что упомянутые рекордсеты достаточно удобны в определенных ситуациях, но у них есть свой недостаток, к ним нельзя применить еще одну выборку, мне придется перебирать его с первого элемента и до последнего, разве нет ? Понятно, что с таблицей таких проблем нет и она может быть включена в любой новый запрос на тех же основаниях, что и обычная.
17 ноя 06, 04:32    [3412547]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Как всегда вполне конкретный вопрос о "СУБД для учета финансовых потоков" перерос в какое-то переругивание о специфике реализации той или иной фичи в БД. Ведь была же здравая мысль, что писать можно на всём, что знаешь. Что такое Ассемблер не все же ещё забыли?

По поводу SQL SERVERa - по моему мнению detached recordsets и temporary tables - это способы избавиться от блокировок, налаживаемых при чтении. У Оракла этой проблемы нет, поэтому он так легко оперирует курсорами (он платит за это в другом месте - напомню про ORA-01555 Snapshot too old). И выборку ему не надо торопиться отсылать на клиента по этой же причине.
ChA
Я готов согласиться, что упомянутые рекордсеты достаточно удобны в определенных ситуациях, но у них есть свой недостаток, к ним нельзя применить еще одну выборку, мне придется перебирать его с первого элемента и до последнего, разве нет ? Понятно, что с таблицей таких проблем нет и она может быть включена в любой новый запрос на тех же основаниях, что и обычная.

Необходимость повторной фильтрации уже выбранных данных говорит о том, что вы что-то забыли добавить в класс WHERE в оригинальном запросе.
17 ноя 06, 20:36    [3418074]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
И что Вы этим примером хотели показать ? Что данные из именованных параметров-рекордсетов считываются точно также, как если бы они считывались из аналогичной процедуры в MSSQL, т.е., последовательно ? Так мне не это было интересно, даже не вызывало сомнений, что это возможно.

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

Оглядываемся чуть назад:

ChA
softwarer
"Нормально" - это возвращать сколько угодно выборок каждую через свой именованный out параметр, а не в виде одной кучи

Допустим. Но этот механизм будет работать только через OCI, но не через ODBC, разве не так ?

Лично я вижу разницу. И рассказывал, что в Oracle запросто можно написать "нормальную" в вышеупомянутом смысле ХП, и ее результат доступен через ODBC.

[чуть более поздняя вставка] Как чувствовал, что Вы скажете, что вопрос был исключительно в неумении ODBC работать с именованными параметрами. Сразу готов ответить: представления не имею, умеет ли вообще ODBC работать нормально или только через свои идиотские вопросики.

ChA
Хммм. Вы сделали утверждение

Да, сделал. Позволю себе не цитировать всю расписанную Вами цепочку, а сразу перейти к финалу.

Cha
Ну и где тут
softwarer
именованные параметры-рекордсеты

В хранимке на сервере. Если Вы забыли, мы обсуждаем различие в возврате рекордсетов из MSSQL и Oracle-хранимок.

Cha
softwarer
и возможность легко крутить выборки так, как нам удобно
, доступные через ODBC ?

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

Cha
И кто после этого выкручивается ?

Ну давайте считать.

1. Кто пытается свести сравнение серверных ХП к нахрен никому не нужному ODBC?
2. Кто при этом задал мне вопрос, который выглядел вполне нормальным профессиональным интересом, а сейчас оказывается его следует читать примерно так: "умеет ли ODBC делать то, чего он делать не умеет?" [примечание - я представления не имею, умеет ли вообще ODBC работать с именованными параметрами, судя по Вашему давлению предполагаю, что не умеет]

Впрочем, этот вопрос уже становится риторическим.

Cha
Замечательно, и через что работает MS SQL Server Transparent Gateway ?

Представления не имею. Можно порыться и выяснить, но мне этого не требовалось. Рыться не хочу ввиду вероятности того, что Вы снова расскажете о том, что знали заранее и это неинтересно.

Cha
При этом он почему-то лучше. По каким критериям ?

По скорости перекачки данных. Кроме того там есть еще вопрос поддержки фич, которые не поддерживаются при работе через ODBC, но они мне не требовались.

Cha
Проводилось тестирование, которое показало безусловное преимущество MS SQL Server Transparent Gateway перед всеми другими вариантами или просто так написано в документации ?

Безусловно, проводилось. В отличие от Вас, я не полагаюсь на "мне кажется".

Cha
Я не ошибусь, если предположу, что упомянутый выше Gateway продается отдельно ?

Именно так, с точностью до устаревания моих сведений. И?

Cha
Еще один риторический вопрос. Если нет общепринятых стандартов, то нахрена, собственно, Oracle вообще поддерживает работу с ODBC, ADO, OLEDB,

Об этом лучше спросить у самого Oracle. По моим впечатлениям, подобную поддержку они пишут по остаточному принципу, почему такое впечатление - потому что слишком уж плохой результат. Выглядит отмазкой для проформы, для того, чтобы всякие идиоты меньше донимали их. В качестве побочной причины можно назвать традиционный маркетоидный вальс - микрософт пишет хреновый драйвер к Oracle, Oracle пишет тоже невпечатляющий, но показывающий, насколько хренов драйвер от Microsoft.

Cha
а также добавляет в свою диалект SQL новые возможности, декларируемые ANSI, например, те же JOIN, которые вам не нравятся ?

Зависит от возможностей. Тот же вышеупомянутый coalesce - удобная вещь, и я рад, что ее добавили. Join - чистой воды маркетинговый ход. Так и быть, открою Вам тайну - в поддержке ansi-шных join-ов регулярно отлавливают баги, при том что они поддерживаются уже лет пять, только на днях (в последнем патчсете) закрыли очередной.

Cha
И где там "существенные накладные расходы" ?

Перекладывание данных во временную таблицу.

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

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

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

P.S. Все-таки, если не трудно, расскажите, что Вы так привязались к этому ODBC? Нехорошая мысль, но не могу отделаться от ощущения, что Ваш любимый инструмент, уж не знаю что, вряд ли Office, просто ничего другого не умеет.
17 ноя 06, 21:49    [3418203]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Anton Demidov
Как всегда вполне конкретный вопрос о "СУБД для учета финансовых потоков"

Мне кажется, вопросы, соответствующие Спросите здесь, какую СУБД лучше выбрать для вашего проекта обречены. Обречены потому, что на самом деле 90% проектов можно сделать в 90% СУБД, а с оставшимися 10% задач работают люди, способные выбрать самостоятельно. Поэтому после фразы "да делайте в чем угодно, что лучше знаете итп" по теме сказать больше нечего, а следовательно начинается флуд.
17 ноя 06, 21:54    [3418218]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
OS/360
Guest
Anton Demidov

По поводу SQL SERVERa - по моему мнению detached recordsets и temporary tables - это способы избавиться от блокировок, налаживаемых при чтении.


Есть и другие применения.
17 ноя 06, 23:33    [3418477]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
OS/360
Anton Demidov

По поводу SQL SERVERa - по моему мнению detached recordsets и temporary tables - это способы избавиться от блокировок, налаживаемых при чтении.


Есть и другие применения.
Кто бы сомневался :) Мы программисты - народ изобретательный.
18 ноя 06, 00:01    [3418535]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
OS/360
Guest
Anton Demidov
OS/360
Anton Demidov

По поводу SQL SERVERa - по моему мнению detached recordsets и temporary tables - это способы избавиться от блокировок, налаживаемых при чтении.


Есть и другие применения.
Кто бы сомневался :) Мы программисты - народ изобретательный.

Но у всех применений есть одно общее - это всё для борьбы с TSQL.
один INSERT EXECUTE чего стоит.
18 ноя 06, 00:13    [3418569]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
Cha
И кто после этого выкручивается ?

Ну давайте считать.

1. Кто пытается свести сравнение серверных ХП к нахрен никому не нужному ODBC?
2. Кто при этом задал мне вопрос, который выглядел вполне нормальным профессиональным интересом, а сейчас оказывается его следует читать примерно так: "умеет ли ODBC делать то, чего он делать не умеет?" [примечание - я представления не имею, умеет ли вообще ODBC работать с именованными параметрами, судя по Вашему давлению предполагаю, что не умеет]

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

А если не в частности или, точнее, а еще как и где, и через какой интерфейс ?

IMHO, был задан конкретный вопрос, с кучей уточняющих, а мне рассказали, что, оказывается, Oracle умеет передавать данные через ODBC. Спасибо, конечно, но я это и так знаю, так же как и то, что практически любой производитель СУБД, как минимум, в обязательном порядке пишет не только native API, но драйвер ODBC для доступа к своей СУБД. Меня всего лишь заинтересовало, что такое "нормально", и есть ли способ воспользоватся таким способом с помощью стандартов, например, того же ODBC. И ежу понятно, что "родной" API обычно богаче возможностями, чем "общепринятые" стандарты. А вдруг ?

softwarer
Рыться не хочу ввиду вероятности того, что Вы снова расскажете о том, что знали заранее и это неинтересно.
Смешно. Правда. Вы ведь здесь не студентам лекции читаете, и если задают вопрос, то не надо начинать с Адама. Если будет что-то непонятно, здесь переспросят, хотя это не всегда помогает. Но приложите хотя бы минимум усилий, чтобы понять, что именно хочет узнать собеседник, а не делать несвязанные друг с другом и контекстом утверждения. Тут их и так более чем достаточно.
softwarer
В отличие от Вас, я не полагаюсь на "мне кажется".
Судя по Вашим ответам, Вам иногда кажется, что Вы отвечаете на заданные вопросы. Кстати, наша предыдущая дискуссия развивалась подобным же образом. И многие другие до того. Мы с Вами как два инопланетянина, вроде говорим на одном языке, но, за редким исключением, категорически не понимаем друг друга. Впрочем, это лирика, забудем.

softwarer
Так и быть, открою Вам тайну - в поддержке ansi-шных join-ов регулярно отлавливают баги, при том что они поддерживаются уже лет пять, только на днях (в последнем патчсете) закрыли очередной.
Я потрясен, а можно я остальным расскажу ?

Мне, собственно, все равно, есть у Oracle проблемы или нет. Также как у IBM с их DB2 и перекупленным Informix, Sybase со всем выводком его клонов и прочими, несть им числа. Соответственно, никогда не было и нет цели доказать, что Oracle, или любой другой по списку является никуда не годным продуктом. Это было бы просто глупостью, у всех есть свои плюсы и свои минусы. Более того, мне совершенно не хочется защищать MS с их SQL Server, пусть даже он сейчас является основным источником моих доходов. Но никак не могу понять, почему некоторые профессионалы в одной СУБД, уверены, что точно знают "слабые" места другой СУБД, в лучшем случае - имеющие с упомянутой достаточно "шапочное" знакомство, причем наверняка, очень давно, но тем не менее, время от времени делают по этому поводу уверенные заявления. Когда подобные заявления делают "мальчики", вчерашние студенты, это понятно - юношеский максимализм, отождествление себя с продуктом, просто заявить о себе, но, более чем странно, видеть такого же рода заявления от "мужей". Возможно, я идеалист, в конце концов, это флеймовый форум, но с другой стороны, он один из немногих, где адепты разных СУБД могли бы обменяться мнениями, у кого какие особенности. Но сплошь и рядом это выливается в свару, hollywar.
softwarer
Cha
И где там "существенные накладные расходы" ?

Перекладывание данных во временную таблицу.
Хорошо, спрошу иначе: почему Вы решили, что это "существенные накладные расходы" ? Поясню, недавно прозвучало уверенное заявление, что таблицы INSERTED и DELETED в триггере строятся невероятно "доооолго". Оказалось, совсем даже нет, просто очередной шум в кустах. Хотелось бы понять, что скрывается за Вашим утверждением.
softwarer
Cha
Я готов согласиться, что упомянутые рекордсеты достаточно удобны в определенных ситуациях, но у них есть свой недостаток, к ним нельзя применить еще одну выборку,

Если задаться такой целью, то можно (в Oracle), но имхо малоосмысленная задача.
Можно ? Каким образом ? Можете проиллюстрировать это скриптом ? В Informix тоже был(и есть) механизм рекордсетов, подобный оному в Oracle, но выбор рекордсета из другого рекордсета или попытка слияния сводились просто к перебору элементов вложенными циклами с проверкой условий на каждом шаге, что было тождественно работе с курсорами в смысле ANSI, только без необходимости выполнять оператор FETCH. Причем, насколько помню, несмотря на то, что это внешне было сильно похоже на перебор, оптимизатор тем не менее тоже принимал в этом посильное участие, хотя может и не всегда удачное, так как он оптимизировал, в первую очередь, сами выборки, но не их слияние.
softwarer
Делать "выборку из выборки" плохо хотя бы тем, что результатом может быть плохой план.
IMHO, несколько сомнительное утверждение. Скорее, наоборот.
Если буду не прав, и к Oracle нижесказанное не имеет отношения, поправьте.
Каждый оптимизатор имеет ограниченное время на оптимизацию и поэтому выбирает, вообще говоря, не оптимальный план, а квазиоптимальный. Если в запросе участвует немного таблиц, то вероятность того, что квазиоптимальный будет оптимальным при заданных условиях достаточно высока. В противном случае, велик шанс, что в отведенное ему время на оптимизацию запроса, любой план, который он выберет может оказаться весьма далек от идеала. Поэтому, разбивая сложный запрос на подвыборки у нас есть шанс, что мы можем сильно облегчить жизнь оптимизатору. При этом, не исключено, что для запроса, включающего все таблицы, существует план, который идеален при исходных условиях, но только на его поиск уйдет гораздо больше времени, чем выполнить несколько подвыборок и слить уже их. Т.е., теоретически идеальный план перестает быть таковым практически.
Разумеется, опытный оптимизатор(программист), потратив некоторое количество времени, может наваять оптимальный план, но только для заданных конкретных условий или их подмножества, но совсем неоптимальный для других. Так как, в общем случае, множество вариантов условий может быть неограниченно(опять же, практически, но не обязательно - теоретически), то оптимизация вручную имеет свои естественные пределы.
Посему мы возвращаемся к предыдущему абзацу и ищем способ помочь оптимизатору(программе). Разумеется, даже при разбиении сложного запроса на подвыборки необходимо включать голову, а не делать это разбиение механически.
softwarer
Временные таблицы имхо подходят, если нужно многократно использовать эти данные, либо формировать их интерактивно.
Насчет интерактивности не уловил, вне контекста, но, кроме многократного использования, еще одно из применений описано выше.
softwarer
Все-таки, если не трудно, расскажите, что Вы так привязались к этому ODBC?
Все просто, в 90 годы приходилось посопрягать разный коней с трепетными ланями, и ODBC был практически единственным способом сделать это без особых сложностей, так как, мало того, что на всех API не напишешься, так еще и не ко всем источником оно существовало, кроме как в виде драйвера ODBC. Так что, слава Богу, стандартом он таки был, хотя Вы ему в этом отказываете. Да, сейчас ему на смену приходит OLEDB, так как ADO, всего лишь надстройка над ним, но, насколько наслышан, есть еще немало проблем при реализации провайдеров, поэтому я лично пока не торопился бы хоронить ODBC. В конце концов, еще хватает источников данных, для которых уже никто и никогда OLEDB-провайдера писать не будет.
18 ноя 06, 05:17    [3418755]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
softwarer
именованные параметры-рекордсеты и возможность легко крутить выборки так, как нам удобно, в частности передавать их между подпрограммами и использовать на сервере.

А если не в частности или, точнее, а еще как и где, и через какой интерфейс ?

Продекларировать набор и сказать "вот это полный список и ничего другого нет", я не рискну. И важного для меня - еще асинхронный фетч. Через все интерфейсы, которые это умеют. OCI и JDBC это умеют, насчет прочих - не проверял.

ChA
Меня всего лишь заинтересовало, что такое "нормально",

Надеюсь, ответ был дан. Во всяком случае, уточняющих вопросов более не последовало.

ChA
и есть ли способ воспользоватся таким способом с помощью стандартов, например, того же ODBC.

Есть. Можно писать "нормальные" ХП и пользоваться ими через ODBC.

ChA
И ежу понятно, что "родной" API обычно богаче возможностями, чем "общепринятые" стандарты.

Что является основной причиной неприменимости "общепринятых" стандартов для серьезных целей.

На всякий случай уточню: еще встречаются.... наивные молодые люди, пытающиеся работать с Oracle через ADO. Бедняги. У яверов практически нет выбора, но там существует возможность расширить драйвер в "нестандартную" сторону, чем Oracle активно пользуется. Что касается пытающихся работать с Oracle через ODBC, то видимо существуют, но в следовых количествах.

ChA
softwarer
Рыться не хочу ввиду вероятности того, что Вы снова расскажете о том, что знали заранее и это неинтересно.
Смешно. Правда. Вы ведь здесь не студентам лекции читаете, и если задают вопрос, то не надо начинать с Адама.

С Адама я начинаю ответ на вопрос, если явный новичок задает вопрос на какую-то серьезную тему - такую, что без знания соответствующего адама наверняка накосячит.

В данном случае я отвечал на заданный вопрос. Так как его понял с учетом предполагаемой грамотности собеседника. Если как Вы сейчас ведете, вопрос был "можно ли писать ХП на ODBC", то такой вопрос я не понимаю.

ChA
Но приложите хотя бы минимум усилий, чтобы понять, что именно хочет узнать собеседник,

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

ChA
softwarer
В отличие от Вас, я не полагаюсь на "мне кажется".
Судя по Вашим ответам, Вам иногда кажется, что Вы отвечаете на заданные вопросы.

(как я люблю логичные ответы) Согласен. И? Где я "полагаюсь" на это "кажется"? Опять же - именно на это "кажется", а не на более материальные критерии, например на отсутствие уточняющих вопросов. Если нигде - причем тут это? Снова какой-то контекст, которого я не понимаю?

ChA
Кстати, наша предыдущая дискуссия развивалась подобным же образом. И многие другие до того.

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

ChA
softwarer
Так и быть, открою Вам тайну - в поддержке ansi-шных join-ов регулярно отлавливают баги, при том что они поддерживаются уже лет пять, только на днях (в последнем патчсете) закрыли очередной.
Я потрясен, а можно я остальным расскажу ?

Хм. Глядя на свое письмо в форуме, на ответ.... такое впечатление, что провоцируете ответить "нет, нельзя".

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

1 Востребованность - просто если представить большой проект на ansi join-ах, да еще и не один а хотя бы каждый десятый, я так думаю, все мыслимые баги были бы отрапортованы наткнувшимися на них куда быстрее

ChA
Но никак не могу понять, почему некоторые профессионалы в одной СУБД, уверены, что точно знают "слабые" места другой СУБД,

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

Лично я как основной источник информации использую утверждение профессионалов, не опровергнутых другими профессионалами. Скажем, для построения задачки имени председателя я использовал FAQ форума MSSQL. Чуть ниже я сошлюсь на Вас.

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

ChA
Хорошо, спрошу иначе: почему Вы решили, что это "существенные накладные расходы" ?

То, что было сказано в топике, в том числе сказано Вами и то, что не опровергнуто Вами, я понял следующим образом: для передачи через ODBC результат выборки формируется целиком. Это означает фактическое удвоение требуемой оперативки2 - в ней будет лежать собственно временная таблица и та же таблица в виде ODBC-ответа. Удвоение потребности в памяти я полагаю существенными расходами. Разумеется, есть и другие тонкие места, но там уже надо уточнять реализацию, прежде чем что-то утверждать, их я в виду не имел.

2 Здесь я предполагаю, что временная таблица целиком лежит в оперативке как более эффективный вариант. Если это не так и таблица уйдет на диск, это будет еще более существенными расходами.

ChA
Поясню, недавно прозвучало уверенное заявление, что таблицы INSERTED и DELETED в триггере строятся невероятно "доооолго".

Насколько я помню, от меня такого заявления не звучало.

ChA
softwarer
Если задаться такой целью, то можно (в Oracle), но имхо малоосмысленная задача.
Можно ? Каким образом ?

Криво и тяжело, примерно как ответ председателя на мою задачу :) Судя по направлению развития, прямая фича такого рода должна появиться, но пока придется извращаться, примерно так3:

SQL> create type TIntTable is table of integer ;

Type created

SQL> create or replace function Reuse ( intable sys_refcursor ) return TIntTable pipelined is
  2    i integer ;
  3  begin
  4    loop
  5      fetch intable into i ;
  6      exit when intable%notfound ;
  7      pipe row ( i ) ;
  8    end loop ;
  9    close intable ;
 10    return ;
 11  end ;
 12  /

Function created

SQL> select
  2    column_value,
  3    chr ( 64 + column_value )
  4  from
  5    table ( Reuse ( cursor ( select rownum from dual connect by level <= 5 ))) ;

COLUMN_VALUE CHR(64+COLUMN_VALUE)
------------ --------------------
           1 A
           2 B
           3 C
           4 D
           5 E

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

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

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

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

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

with
  subquery1 as ( select .. from A, B, C where ..),
  subquery2 as ( select .. from D, E where ..)
select
  ..
from
  subquery1, subquery2
where
  ..

Здесь subquery1 и subquery2 - те подзапросы, на которые Вы разбили бы большой запрос. Так вот, вполне может оказаться, что Вы совершенно правы, и A join B и D join E стоит выполнять прежде других операций, но вот C с точки зрения оптимальности стоит подсоединять самой последней. Однако! Однако C должна быть подсоенинена в первый запрос с точки зрения логики, понимания смысла этого запроса. Хинты в общем запросе дадут здесь оптимум, а разбиение ведет к неприятной коллизии, которая - если говорить о практике - скорее всего будет разрешена не в сторону эффективности.

ChA
Насчет интерактивности не уловил, вне контекста,

Ну, самый простой пример такой функциональности - "искать в найденном". То есть временная таблица формируется последовательностью команд пользователя, не просто как промежуточные данные для единственной операции.

ChA
В конце концов, еще хватает источников данных, для которых уже никто и никогда OLEDB-провайдера писать не будет.

Я бы сказал, уже хватает источников, для которых никто и никогда не будет писать ODBC-драйвер. Собственно, многолетняя неисправляемая Microsoft-ом кривизна ODBC-драйвера экселя это иллюстрирует.
18 ноя 06, 13:15    [3419097]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
что-то непонял с именоваными ref_cursors, любой вменяемый инструмент у меет нормально с этим работать в jdbc умеет, .Net через ODP.NET умеет, всякие php,perl работают через OCI. что там еще бывает, делфи, через что там делфи работает ?

http://www.oracle.com/technology/pub/articles/mastering_dotnet_oracle/williams_refcursors.html
The MultipleActiveResultSets method illustrates a feature of Oracle Data Provider for .NET, by retrieving and "randomly" processing multiple result sets that are concurrently active. This feature has been available since the first version of ODP.NET. In addition, note that this code "skips" the second ref cursor during processing. The first and third result sets are retrieved to the .NET client, but the second result set's data is deferred and remains on the database server. This improves response time, because the second result set's data retrieval can be deferred until a time when it may be needed.
18 ноя 06, 13:53    [3419141]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
ChA
softwarer
в поддержке ansi-шных join-ов регулярно отлавливают баги, при том что они поддерживаются уже лет пять, только на днях (в последнем патчсете) закрыли очередной.
...
...

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

1 Востребованность - просто если представить большой проект на ansi join-ах, да еще и не один а хотя бы каждый десятый, я так думаю, все мыслимые баги были бы отрапортованы наткнувшимися на них куда быстрее
Когда таковые впервые появились в MSSQL, то ими тоже несколько лет мало кто пользовался. И до сих пор можно встретить программистов, которые их игнорируют, по незнанию ли, по непониманию ли, или еще по каким-то третьим причинам. Но, как правило, это либо новички, либо перешедшие с других платформ, в то время как все разработчики, квалификация которых оценивается на профильном форуме достаточно высоко, поголовно используют такой синтаксис. Просто как факт, не более.
А то, что востребованность их невелика среди адептов Oracle, скорее всего связано именно с определенными возможностями языка. Рискну предположить, что в их коде очень часто встречается манипуляции с данными через рекордсеты, то чего лишен MSSQL, возможности которого, за редким исключениям, не выходят за рамки ANSI и ограничены операциями над множествами. Хотя появление 2005, возможно, что-то меняет, но, к сожалению, пока не до него, посему ничего внятного в его адрес.
softwarer
для передачи через ODBC результат выборки формируется целиком. Это означает фактическое удвоение требуемой оперативки - в ней будет лежать собственно временная таблица и та же таблица в виде ODBC-ответа. Удвоение потребности в памяти я полагаю существенными расходами.
Понял.
По поводу первого предложения, то нет, насколько мне известно, тем более в случае возврата множественных рекордсетов. Например, выполнив
CREATE TABLE t(id int, n int)
GO
INSERT INTO t(id, n)
SELECT 1, 1
UNION ALL SELECT 2, 2
UNION ALL SELECT 3, 0
GO
CREATE PROCEDURE p AS
SELECT id, id/n FROM t WHERE id = 1
SELECT id, id/n FROM t WHERE id = 3
SELECT id, id/n FROM t WHERE id = 2
GO
exec p
SELECT id, id/n FROM t
GO
DROP PROCEDURE p
DROP TABLE t
через QA, который тоже работает через ODBC, можно увидеть, что результаты возвращаются по мере вычисления, при этом ошибка не мешает возврату последующих результатов, если этим специально не озаботиться.
Результат:
id                      
----------- -----------
1 1

Server: Msg 8134, Level 16, State 1, Procedure p, Line 3
Divide by zero error encountered.
id
----------- -----------
2 1

id
----------- -----------
1 1
2 1

Server: Msg 8134, Level 16, State 1, Line 2
Divide by zero error encountered.

По поводу второго. Не совсем уловил ход мысли, не вижу связи между ODBC и временной таблицей. Тем более, что в первом случае - это память клиента, а во втором - сервера. А где хранится временная таблица, в ОЗУ или в tempdb, - неважно, ее использование должно быть оправдано в любом случае, например, повышением общей производительности или большей предсказуемостью поведения. Если она позволит выполнить какой-либо SQL-код быстрее, чем без ее использования, то вполне естественно, что за это придется чем-то платить, например, расходом памяти. В принципе, качели "память - скорость" - частое явление при программировании, по крайней мере, по моему опыту.

softwarer
Судя по направлению развития, прямая фича такого рода должна появиться, но пока придется извращаться, примерно так...
Угу, понятно, т.е. посредством некоей новой сущности pipe, и общей оптимизации, наверное, выполняться при этом не будет. В любом случае, механизм, какой-никакой, но все-таки есть. В Informix такого не помню, хотя с того времени много чего изменилось, может и добавилось.

softwarer
Сказанное скорее верно, хотя и с оговорками - скажем, там подразумевается, что план вычисляется для каждого запроса, в то время как переиспользование плана - основа эффективности большинства систем, в том числе, насколько мне известно, и в MSSQL. Но вопрос в выводах, которые следует сделать.
Если "там", это мой текст, то совсем нет, переиспользование плана там не отрицалось, это, IMHO, несколько иная тема. Но если мы ее подняли, то тут свои проблемы. Переиспользование плана тоже не всегда оптимально. Например, если есть сомнения, что конкретные условия для одного и того же по синтаксису запроса ведут к одному и тому же оптимальному плану, то в MSSQL можно указать, что процедуру надо каждый раз перекомпилировать, а не пользоваться одним и тем же планом(но можно сделать и наоборот, т.е., не стоит напрягаться, но только для конкретных запросов).
Скажем так, встречался с запросами, компиляция которых настолько превышает время выполнения, что приходится делать телодвижения, дабы избегать таких несуразностей. В том числе, переписывая запрос, вплоть до разбиения его на последовательность более простых. Разумеется, это не частое явление, но изредка бывает. А если учесть, что запросы все равно время от времени перекомпилируются, например, при изменении табличных статистик, то можно заранее подстраховаться и сделать поведение более предсказуемым. Об актуальности таких методов для Oracle судить не могу, не моя епархия. Возможно, там свои способы...

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

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

with
  subquery1 as ( select .. from A, B, C where ..),
  subquery2 as ( select .. from D, E where ..)
select
  ..
from
  subquery1, subquery2
where
  ..

Здесь subquery1 и subquery2 - те подзапросы, на которые Вы разбили бы большой запрос. Так вот, вполне может оказаться, что Вы совершенно правы, и A join B и D join E стоит выполнять прежде других операций, но вот C с точки зрения оптимальности стоит подсоединять самой последней. Однако! Однако C должна быть подсоенинена в первый запрос с точки зрения логики, понимания смысла этого запроса. Хинты в общем запросе дадут здесь оптимум, а разбиение ведет к неприятной коллизии, которая - если говорить о практике - скорее всего будет разрешена не в сторону эффективности.
Когда такое разбиение применяется для оптимизации, то понимания запроса, IMHO, уходит на второй план. Ну и, есстественно, это может подпадать под оговорку
ChA
даже при разбиении сложного запроса на подвыборки необходимо включать голову, а не делать это разбиение механически.
Кроме того, если отталкиваться от Вашего запроса выше, то, вполне может быть, что такие предвыборки через WITH могут уже формироваться как внутренние рекордсеты, которые вычисляются только один раз, и уже затем включаются в общий план. Это вотчина оптимизатора, и не исключено, что он может принять и такое решение. Впрочем, это только мои предположения, которые основываются на логике поведения оптимизатора MSSQL, который вполне может сам использовать внутренние временные таблицы, если найдет это полезным. А если я создаю эти таблицы явно и буду их использовать, то это, в принципе, ничем не отличается от того, что делает сервер.

softwarer
ChA
Насчет интерактивности не уловил, вне контекста,

Ну, самый простой пример такой функциональности - "искать в найденном". То есть временная таблица формируется последовательностью команд пользователя, не просто как промежуточные данные для единственной операции.
Хммм, с таким применением временных таблиц лично мне сталкиваться не приходилось. Возможно просто не встречались задачи, где бы этот способ был оправданным. В крайнем случае, для поддержки фильтрации использовалась постоянная таблица, где хранились идентификаторы записей, разнесенные по сессиям.
18 ноя 06, 21:02    [3419922]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Главрыба
Guest
Председатель Мао
По такой схеме: Модем-брандмауэр-Сервер FreeBSD (прокси) - проборос на сервер с Win2к3. Планируется только ХП абсолютно на все действия юзера. В локалке будет 7-8 юзеров. Филиалов порядка 50. .....Но все же может, есть нечто другое для данной задачи. Выскажите свои мнения по этому поводу. Спасибо.


Посмотрите в сторону технологии Cache Server Pages от Intersystems.
Видел решения в аналогичной ситуации на ~30 филиалов, в филиале локальная сеть. Сопровождает 1 человек удаленно.
18 ноя 06, 23:07    [3420128]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
softwarer
Мимопроходящий
ну а ныне, к примеру, стоимость = количество * цена,
если любой из операндов NULL, то результат NULL, вполне логичен.

Он логичен математически. Но нелогичен и неудобен по бизнесу, с точки зрения решения практических задач.

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


это потому, что вы NULL переводите как "ноль". Переводите как "неизвестен", и все сразу станет логично с точки зрения бизнеса - цена неизвестна, значит, и расходы неизвестны.
19 ноя 06, 02:42    [3420403]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Выбегалло
softwarer
Соглашусь с тем, что ему можно придать практический смысл, что-нибудь типа "мы покупаем 10 тонн конопли, цена еще не известна,

это потому, что вы NULL переводите как "ноль". Переводите как "неизвестен",

Хм. Так и не понял, на основании каких данных Вы сумели выдвинуть столь... смелую гипотезу о бытующем у меня переводе "null".
20 ноя 06, 12:50    [3423765]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
По поводу первого предложения, то нет, насколько мне известно, тем более в случае возврата множественных рекордсетов. Например, выполнив

Может быть, я чего-то не понял, но я пока не уверен, что Ваш пример демонстрирует что-либо кроме того, что MSSQL продолжает работу после ошибки (что в общем-то и так известно). Мало того, судя по тому, что Вы возвращаете рекордсеты из одной записи, Вы не поняли, что я имел в виду.

Я имел в виду следующее. Допустим, нужно вернуть выборку на 1'000'000 записей (такую большую - чтобы в дальнейших рассуждениях смело пренебречь незначимыми слагаемыми). Если просто написать select, затраты памяти в ходе операции составят 1'000'000 условных единиц в буфере результатов процедуры. Если написать create temp table / copy data / select from temp table, затраты памяти составят 1'000'000 условных единиц в tempdb (кажется, там хранятся временные таблицы?) и 1'000'000 условных единиц в буфере результатов процедуры.

ChA
По поводу второго. Не совсем уловил ход мысли, не вижу связи между ODBC и временной таблицей. Тем более, что в первом случае - это память клиента, а во втором - сервера.

Нет. То и другое - память сервера.

ChA
А где хранится временная таблица, в ОЗУ или в tempdb, - неважно, ее использование должно быть оправдано в любом случае, например, повышением общей производительности или большей предсказуемостью поведения.

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

Оправдано ли будет такое внедрение - надо смотреть в каждом конкретном случае. Связь между "дополнительными накладными расходами" и "повышением производительности" не то чтобы безусловно...

ChA
Если она позволит выполнить какой-либо SQL-код быстрее, чем без ее использования

Не надо уводить в сторону. Мы говорим о возврате этой выборки. Клиент, делающий exec proc, никакой дополнительный SQL-код не выполняет.

ChA
т.е. посредством некоей новой сущности pipe,

Да нет, pipelined function здесь сугубо необязательна. Ту же функцию можно было бы написать без нее с тем же результатом, примерно так:

create or replace function Reuse ( intable sys_refcursor ) return TIntTable is
  result TIntTable := TIntTable() ;
begin
  loop
    fetch intable into i ;
    exit when intable%notfound ;
    result.expand ;
    result ( result.last ) := i ;
  end loop ;
  close intable ;
  return result ;
end ;

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

ChA
и общей оптимизации, наверное, выполняться при этом не будет. В любом случае, механизм, какой-никакой, но все-таки есть.

Общей оптимизации не будет. Насчет механизма - дык собственно :)

ChA
переиспользование плана там не отрицалось

Не отрицалось, конечно, просто не предусматривалось. Рассуждения неявно опирались на "один parse - один/мало execute". Скажем, в ситуации "один parse - десять миллионов execute" время, потраченное на построение плана, становится намного менее важным, а вот вероятность упустить хороший план из-за разбиения на подзапросы - намного более критичной.

ChA
, это, IMHO, несколько иная тема. Но если мы ее подняли, то тут свои проблемы.

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

ChA
Когда такое разбиение применяется для оптимизации, то понимания запроса, IMHO, уходит на второй план.

Если обратите внимание, я и говорю о коллизии, которая подстерегает на этом пути. Конфликте "удобного" с "оптимальным".

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

ChA
Кроме того, если отталкиваться от Вашего запроса выше, то, вполне может быть, что такие предвыборки через WITH могут уже формироваться как внутренние рекордсеты, которые вычисляются только один раз, и уже затем включаются в общий план. Это вотчина оптимизатора, и не исключено, что он может принять и такое решение.

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

ChA
А если я создаю эти таблицы явно и буду их использовать, то это, в принципе, ничем не отличается от того, что делает сервер.

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

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

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

1. Сохранение контекста к следующему сеансу того же пользователя
2. Трехзвенные извращения.
20 ноя 06, 14:02    [3424345]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
ChA
По поводу первого предложения, то нет, насколько мне известно, тем более в случае возврата множественных рекордсетов. Например, выполнив

Может быть, я чего-то не понял, но я пока не уверен, что Ваш пример демонстрирует что-либо кроме того, что MSSQL продолжает работу после ошибки (что в общем-то и так известно).
Да, пожалуй, неубедительно :(
Итак, снова возвращаемся к первоначальному утверждению
softwarer
для передачи через ODBC результат выборки формируется целиком.
Можно, конечно, воззвать к разуму, что бессмысленно и совершенно неоптимально накапливать на сервере весь рекордсет, пока не закончится выполнение запроса. Таким образом мы можем дойти до того, что практически невозможно получить выборку, объем которой превышает объем ОЗУ доступного серверу MSSQL. И вряд ли хоть один сервер RDBMS может позволить себе работать подобным образом. Понятно, что это сотрясание воздуха. Но мне совсем не хотелось размахивать здесь C-кодом, использующем ODS(Open Data Service), так как технические детали для общего понимания процесса совершенно неважны. Посему позвольте просто процитировать некоторые выдержки из книги "Inside Microsoft SQL Server 2000"
Kalen Delaney
ODS manages the network: it listens for new connections, cleans up failed connections, acknowledges "attentions" (cancellations of commands), coordinates threading services to SQL Server, and returns result sets, messages, and status values back to the client.

SQL Server clients and the server speak a private protocol known as Tabular Data Stream (TDS). TDS is a self-describing data stream. In other words, it contains tokens that describe column names, datatypes, events (such as cancellations), and status values in the "conversation" between client and server. The server notifies the client that it is sending a result set, indicates the number of columns and datatypes of the result set, and so on—all encoded in TDS. Neither clients nor servers write directly to TDS. Instead, the open interfaces of OLE-DB, ODBC, and DB-Library at the client emit TDS using a client implementation of the Net-Library.
...
After SQL Server puts result sets into a network output buffer (write buffer) that's equal in size to the configured packet size, the Net-Library dispatches the buffer to the client. The first packet is sent as soon as the network output buffer is full or, if an entire result set fits in one packet, when the batch is completed.
...
In some exceptional operations (such as one that provides progress information for database dumping or provides DBCC messages), the output buffer is flushed and sent even before it is full or before the batch completes.
...
SQL Server has two input buffers (read buffers) and one output buffer per client.
...
Надеюсь, этой информации достаточно, чтобы согласиться с тем, что результат выборки не копится целиком, чтобы только по окончанию отослать его клиенту. Причем такое поведение не зависит от способа, которым оный получает результат, т.е., через ODBC, OLE-DB или DB-Library.
softwarer
Я имел в виду следующее. Допустим, нужно вернуть выборку на 1'000'000 записей (такую большую - чтобы в дальнейших рассуждениях смело пренебречь незначимыми слагаемыми). Если просто написать select, затраты памяти в ходе операции составят 1'000'000 условных единиц в буфере результатов процедуры. Если написать create temp table / copy data / select from temp table, затраты памяти составят 1'000'000 условных единиц в tempdb (кажется, там хранятся временные таблицы?) и 1'000'000 условных единиц в буфере результатов процедуры.
Исходя из вышесказанного, надеюсь понятно, что каким бы способом не заполнялась временная таблица, SELECT-ом ли, EXEC-ом ли, никакого двойного хранения в памяти миллиона строк не будет. Надеюсь, вопрос закрыт ?

softwarer
ChA
А где хранится временная таблица, в ОЗУ или в tempdb, - неважно, ее использование должно быть оправдано в любом случае, например, повышением общей производительности или большей предсказуемостью поведения.

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

Оправдано ли будет такое внедрение - надо смотреть в каждом конкретном случае. Связь между "дополнительными накладными расходами" и "повышением производительности" не то чтобы безусловно...

ChA
Если она позволит выполнить какой-либо SQL-код быстрее, чем без ее использования

Не надо уводить в сторону. Мы говорим о возврате этой выборки. Клиент, делающий exec proc, никакой дополнительный SQL-код не выполняет.
Опять момент, когда я перестаю Вас понимать. Я говорю, что нет никакой разницы, где находиться временная таблица, в памяти или в tempdb, так как если она используется, то осмысленно и c конкретной целью. А в ответ почему-то получение обвинения в уводе темы в сторону.
Временная таблица - это обычная таблица, но с некоторыми оговорками, и если я говорю, что она храниться в памяти, то это не потому, что можно выбирать, где ее хранить, а потому что в памяти есть свободное место для ее хранения там целиком. Если таблицу долго не использовать, то она постепенно может быть вытеснена в tempdb на диск, если серверу не будет хватать памяти для более полезных вещей. Если она получится очень большой, то почти наверняка будет сразу вытеснена в tempdb, хотя и не полностью, в памяти останется несколько страниц, которые тоже могут быть вытеснены по "старению". Когда клиент, кто бы он ни был, снова вспомнит о ней, она начнет "подниматся" в память, в зависимости от наличия свободного места в ОЗУ, целиком или только те фрагменты о которых "вспомнили".
Не надо придавать временной таблице никакого мистического смысла, сервер работает с такой таблицей почти также, как и с постоянными, включая логирование. Просто сервер при работе с tempdb, позволяет себе некоторые вольности, типа ослабления поддержки WAL, т.е., не торопится сбрасывать лог на диск, а это уже дорогого стоит. Плюс, чуть иначе, если правильно помню, выделяет страницы под создаваемые таблицы с учетом основной ее роли - хранилища временных данных. Наверняка что-то еще, это просто навскидку.

softwarer
ChA
переиспользование плана там не отрицалось
Не отрицалось, конечно, просто не предусматривалось. Рассуждения неявно опирались на "один parse - один/мало execute". Скажем, в ситуации "один parse - десять миллионов execute" время, потраченное на построение плана, становится намного менее важным, а вот вероятность упустить хороший план из-за разбиения на подзапросы - намного более критичной.
Могу только повторить
ChA
, это, IMHO, несколько иная тема.
Мной рассматривалась вполне конкретная ситуация, когда от разбиения можно получить выгоду и немалую. Даже в ситуации "один parse - десять миллионов execute" иногда лучше получить предсказуемый ответ в течении 10 единиц времени, чем через каждую, например, сотню вызовов с ценой 5 единиц получать задержку в 1000 единиц, которая может вызвать лавинообразный рост задержек, так как процессор в это время не простаивает, а усиленно пытается построить план. Но, IMHO, все это гипотезы и жонглирование цифрами, решение всегда принимается по месту, с активным использованием серого вещества, о чем неоднократно упоминалось выше.

softwarer
Эту тему я пару раз здесь поднимал, но к сожалению не нашлось человека, который мог бы достаточно детально рассказать о поведении MSSQL в интересных случаях. Если Вы чувствуете в себе силы для неторопливой беседы на эту тему, наверное стоит создать отдельный топик, причем аккуратно - то есть договориться о терминологии, обменяться рассказами о том "как оно делается в нашем случае", составить список вопросов, представляющих особый интерес...
Если честно, то у меня начинается очередно насыщенный период, боюсь, я просто не в состоянии буду уделять много времени в ближайшее время. Даже сейчас я "ворую" рабочее время :) Так что неторопливая беседа может, более чем сильно, затянуться. Особенно, если "размахиваться" как сейчас, килобайтами. Было бы намного проще, короткий вопрос - короткий ответ, но, к сожалению, между нашими платформами столь глубокие различия, что такой вариант вряд ли пройдет.

softwarer
Здесь стоит вспомнить, что речь о разбиениях зашла не просто так, а в контексте использования одной хранимкой результата другой хранимки. Здесь "удобно" - уже не просто "удобно так писать запрос", а интерфейс, публичная часть решения. Подлаживание его под физику, под реализацию - неправильно с точки зрения проектирования.
С этим согласен полностью. В этом смысле можно было бы сделать и поизящнее, чем это присутствует в MSSQL(2000) сейчас, включая ограничения на вставку через EXEC, а у OPENQUERY свои заморочки.

softwarer
ChA
А если я создаю эти таблицы явно и буду их использовать, то это, в принципе, ничем не отличается от того, что делает сервер.
Отличается тем, что Вы вяжете оптимизатору руки, не оставляете ему выбора.
Так в этом и состояла моя цель, нефиг ему гадать, я лучше знаю, как здесь поступить и готов платить за это, в том числе, потерей "прозрачности" кода и беря на себя ответственность за последствия. Возможно в Oracle оптимизатор никогда не принимает неверных решений. MSSQL же может делать "промашки", на это влияет очень много факторов. И в этом даже синтаксис может сыграть свою роль, например, лишнее условие, которое оптимизатор будет должен учесть, или лишнее поле в результате, которое нужно там не больше, чем собаке пятая нога. Согласен, что хотелось бы идеала, но разработчики БД сплошь и рядом вынуждены учитывать "физику", а не только концептуальную модель. Попробуйте оставить таблицы без индексов, результат может превзойти все ожидания :)
Впрочем, Вам об этом рассказывать не имеет смысла, Вы и сами можете многое рассказать, насколько понимаю.

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

1. Сохранение контекста к следующему сеансу того же пользователя
2. Трехзвенные извращения.
Ни то, и ни другое. Именно рекурсивная пользовательская фильтрация. Он делает по условиям одну выборку, потом из нее другую, разумеется, через соответствующий интерфейс, потом эта выборка передается на массовую обработку, в том числе - внутренним языком. В принципе, можно было бы реализовать ту же функциональность через временные таблицы, но это было сложнее для реализации на клиенте, если правильно помню.
21 ноя 06, 04:32    [3427352]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить