Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 23   вперед  Ctrl
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
Однако, очень смело с Вашей стороны за "всех" обычных программистов высказываться.

Проведите эксперимент. Возьмите сто программистов, не знающих SQL, покажите им текст этой процедуры и спросите, что она возвращает в качестве результата.

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

pkarklin
Позволю себе с Вами не согласиться. С чего бы это "не знающему SQL программисту" надо различать:

CREAT VIEW ... AS SELECT... и CREATE PROC ... AS SELECT...?

А Вы уверены, что он их различает? Имхо для "не знающего SQL" разница будет только в том, что он может быть знает, что такое "процедура" но заведомо имеет представления, что такое view.

pkarklin
Почему в одном случаи SELECT что-то возвращает, а во втором он недолжен ничего возвращать.

В первом случае селект точно ничего не возвращает. Во втором - его поведение... непрозрачно.

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

pkarklin
А еще болеше надо догадаться, что для того, чтобы что-то вернуть из CREATE PROC нужно знать синтаксис некоего PL\SQL, а не основы ANSI SQL.

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

С возвратом из хранимок в MSSQL вообще много забавного. Помнится, когда я только поставил его, попробовал примерно следующий подход:

create procedure p1 @data int output as
  set @data = 1
  return @data
go

create procedure p2 @data int output as
  exec p1 @data
go

declare @data int
exec p1 @data
print coalesce (@data, -666)
exec p2 @data
print coalesce (@data, -666)

Сразу оценил прозрачность, очевидность и прочую возможность программировать, зная только ANSI SQL. Кстати, а с каких пор ANSI SQL позволяет возвращать данные из ХП таким образом?

pkarklin
Хм... Я не делал вывод я спросил:

Хм. "Выводить" - это не совсем "делать вывод", русский язык здесь содержит неоднозначность. "Выводить" - это to derive, обладающий такими синонимами, как "производить", "извлекать". Ваш вопрос, надеюсь, задан не с бухты барахты? Нет же? Он опирается на предыдущий материал, произведен от него, выведен из него. "Вы выводите" - читается соответственно.

pkarklin
И вопрос этот был навеян некоторыми высказываниями участников обсуждения:

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

А я спрошу - какое отношение это навеяло имеет к удивившей Вас прозрачности?

pkarklin
И это я слышу не первый раз. Так что же все-таки с реф-курсорами?

Хм. С моей точки зрения - ничего. Пользуюсь. Что имели в виду джентльмены, спросите у них.

pkarklin
Хотя существует возможность возвращать из хп более чем один резалтсет я противник такого подхода именно из-за приведенных Вами предыдущего и следующего недостатков.

Хм. Тогда как промежуточный итог можно записать плюсы-минусы в графу "удобный возврат нескольких выборок из одной ХП". Подход Oracle, как Вы понимаете, совершенно индиффирентен к количеству out параметров.

Однако, то, что Вы против такого подхода, совершенно не спасает Вас от следующего эффекта:

create procedure p1 as
  declare @i int
  set @i = 1
  select * from digits where i = @i
go

create procedure p2 as
  exec p1
  declare @i int
  set @i = 2
  select * from digits where i = @i  
go

create table #Temp (i int)

insert into #Temp exec p2

select * from #Temp

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

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

pkarklin
softwarer
Во-первых, прозрачность этой конструкции является фактом только для Вас. Имхо для любого нормального программиста "прозрачным" является возвращение результата функции через "собственно результат" и out параметры.

Если возможности языка это позволяют, то почему бы не рассматривать это как дополнительную возможность, а не как "извращение"?

И снова Вы уходите от темы как только Ваше же собственное утверждение начинает Вам мешать.

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

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

Зато я готов.

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

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

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

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

Фи. Грубо и некрасиво передергиваете. Код-то как раз прозрачен, думаю, ни у кого из присутствующих нет вопроса, что же он делает.

А вот поведение сервера в этом случае - совершенно непрозрачно. Хотя Вы, конечно, вправе придерживаться особого мнения. Тогда так и говорите: "для меня после чтения документации и N лет практического использования все прозрачно".

pkarklin
Нет.

OK. По сути это уже обсуждено выше, так что без дополнительных комментариев.

pkarklin
softwarer
Как Вам сказать..... это бессмысленный вопрос, из серии "ты перестала пить коньяк по утрам"? На него можно ответить только объяснением того, что предпосылки, на которые он опирается, являются ложными.


Это не ответ.

Это лучший ответ, который я могу дать, не погружаясь в долгие и подробные объяснения "почему этот вопрос бессмысленен". То, что Вы спрашиваете, сродни старому анекдоту:

Студент спрашивает профессора: "Иван Андреевич, я изучил электротехнику, я все понимаю,
не могу понять только одного. Скажите пожалуйста, как вот такой (рука рисует синусоиду)
ток идет по вот такому (рука проводит прямую) проводу?"
29 янв 07, 17:00    [3708980]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
kennethr
А применение для такой формы вполне реальное, ограничение доступа к объектам. softwarer, это не вам :-)

Реальное где? В Oracle этой формой для ограничения доступа к объектам будут пользоваться только ламеры, желающие сделать "как привыкли".
29 янв 07, 17:01    [3708998]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Bogdanov Andrey
Если я выполняю select-запрос, то его спецификация "заключена" в select-list, если я вызываю процедуру, то ее спецификация - описание параметров

и вот такой запрос вернёт однозначный результат?
автор
if @a>@b select * from A else select * from B

softwarer
Давайте смотреть. С точки зрения любого "обычного" программиста, то есть - не знакомого специально с этой фичой, возврат набора данных в результате SELECT - крайне неочевидный побочный эффект. Думаю, Вы согласитесь, что есть взять не знающего SQL программиста и показать ему "подпрограмму из одного SELECT", он в жизни не догадается, что оказывается она что-то возвращает. Если же показать ему аналогичную подпрограмму на PL/SQL - догадается, синтаксис там вполне традиционный.

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

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

Преимущества микросовтовской концепции хп - как ни странно - полная неопределённость в возврате результатов.
Допустим у меня процедура делает какие-то сложные расчеты. Я могу вставить посреди процедуры вывод промежуточных результатов - просто напишу нужный select и всё, не надо ничего объявлять.
Хотя надо признать что передача массива данных от одной процедуре к другой оставляет желать лучшего(у MS). Приведённый выше пример insert into #Temp exec [master].[dbo].[ManyDigits] не допускает вложенности(в самой ManyDigits такое уже делать нельзя), требует создания временных таблиц. Передать результат запроса в процедуру тоже практически невозможно, я для этого как-то специально вместо процедуры использовал insted of триггер.
И прогресс в этом очень слабый. В версии 6.0 появился insert into #Temp exec, в 2000 - функции, в 2005 - по-моему ничего (output несколько из другой оперы). До передачи таблицы как параметр наверное не доживу.
pkarklin

softwarer
- существует ли в MSSQL возможность передать выборку из серверной ХП на клиент, используя как механизм передачи параметры подпрограммы и работая на клиенте с полученной выборкой нормальным для дельфы образом?

Нет.

Скажем так: в MSSQL существует возможность передать выборку(одну или несколько) из серверной ХП на клиент, работая на клиенте с полученной выборкой нормальным для дельфы образом
29 янв 07, 17:12    [3709083]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper
Скажем так: в MSSQL существует возможность передать выборку(одну или несколько) из серверной ХП на клиент, работая на клиенте с полученной выборкой нормальным для дельфы образом


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

Реализацию серверных курсоров с помощью серверного АПИ здесь я не рассматриваю.
29 янв 07, 17:24    [3709190]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
SergSuper

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


Отлично. И все, кто пытался использовать эту процедуру идут лесом, потому как неожиданно у процедуры изменился набор возвращаемых результатов. А еще более забавна ситуация, когда этот самый "нужный select" обернут в некий if.
Честно скажу я вижу огромное преимущество у типизированных языков перед нетипизированными, а особенно при разработке достаточно объемных проектов. Ну а "слабать на коленке" можно на любом языке.
И вот в этом месте между концепциями заложенными в Oracle и в MSSQL громадная разница. MSSQL ориентирован на непрофессионалов, стремящихся быстро и не вдаваясь в концепции сваять что-то работающее. А Oracle изначально ориентировался на серъезную разработку.
Естественно, ориентация на непрофессионалов не делает невозможным использование MSSQL профессионалами, но в этом случае его достоинства превращаются в недостатки.
29 янв 07, 17:56    [3709422]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
А вот у меня абсолютно противоположное мнение! .... Давайте не будем спорить что лучше, что хуже.

Замечательно. Я с этим соглашусь - если Вы пойдете и убедите в том же pkarklin-а, который начал спорную тему прозрачности.

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

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

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

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

SergSuper
Скажем так: в MSSQL существует возможность передать выборку(одну или несколько) из серверной ХП на клиент, работая на клиенте с полученной выборкой нормальным для дельфы образом

Я не зря упираю в передачу через параметры. Чем замечательны параметры? Допустим, я пишу следующую процедуру:

create procedure GetSomething ( type1 out sys_refcursor, type2 out sys_refcursor ) as
begin
  open type1 for select * from table where type = 1 ;
  open type2 for select * from table where type = 2 ;
end ;

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

И вот тут есть интересный момент. Можно ли обязать программиста помнить об этом? Да, можно в принципе. Если программист квалифицированный. Неквалифицированный таким вот "просто вставить" сломает нахрен всю систему, и вовсе не по злому умыслу. Впрочем, с моей точки зрения, и квалифицированного грузить этим совершенно нерационально, у него есть дела поважнее.
29 янв 07, 18:00    [3709445]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Проведите эксперимент. Возьмите сто программистов, не знающих SQL, покажите им текст этой процедуры и спросите, что она возвращает в качестве результата.

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


Т.е. Вы уверены, не проводя эксперимента в своей правоте, а я в подтверждении своей должен поставить эксперимент? Увольте. Я останусь при своей точке зрения.

softwarer
А Вы уверены, что он их различает?


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

softwarer
В первом случае селект точно ничего не возвращает. Во втором - его поведение... непрозрачно.


SELECT не возвращает ничего в обоих случаях. Пока не будет обращения к конкретному объекту с конкретным синтаксисом.


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


Но это опять же Ваша точка зрения, а не не знающего SQL.

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


Действительно, сначала надо изучить SQL, затем PL\SQL. Да еще не забыть, что такие хп только в пакетах можно создавать. Я не прав? И что будет "прозрачнее" для не знающего?

softwarer
С возвратом из хранимок в MSSQL вообще много забавного. Помнится, когда я только поставил его, попробовал примерно следующий подход...

Сразу оценил прозрачность, очевидность и прочую возможность программировать, зная только ANSI SQL. Кстати, а с каких пор ANSI SQL позволяет возвращать данные из ХП таким образом?


Странно, как Вам не пришла в голову "страшная и кощунственная мысль изучить используемый инструмент, т.е. заглянуть в хелп по инструкции CREATE PROC и EXEC.

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

softwarer
Хм. "Выводить" - это не совсем "делать вывод", русский язык здесь содержит неоднозначность

...
Он опирается на предыдущий материал, произведен от него, выведен из него. "Вы выводите" - читается соответственно.


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


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


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

softwarer
Однако, то, что Вы против такого подхода, совершенно не спасает Вас от следующего эффекта:
...
Пакость же в том, что p1 может делать что-то нужное p2, а возврат в нее выборки могут добавить не сразу, а много позже, когда Вы уже давно отладили и сдали p2, да и вызов может идти не так очевидно, а через триггер.

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



С таким же успехом, "дополнительными проблемами при коллективной разработке и особенно при сопровождении" м.б. следующее:

CREATE VIEW View1 
AS
  SELECT * FROM Table1 WHERE id = 1
GO

А теперь, гораздо позже:

ALTER VIEW View1 
AS
  SELECT * FROM Table1 WHERE id = 1
  UNION ALL
  SELECT * FROM Table2 WHERE id = 2
GO

Теперь что будет с хп, возвращающей ref-курсор на основе SELECT * FROM View1. Осмелюсь предположить, что ничего. И таких "проблем" можно напридумывать кучу.

softwarer
И снова Вы уходите от темы как только Ваше же собственное утверждение начинает Вам мешать.

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


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

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

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

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


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

softwarer
Фи. Грубо и некрасиво передергиваете. Код-то как раз прозрачен, думаю, ни у кого из присутствующих нет вопроса, что же он делает.


У меня, как у одного из присутсвующих, возникает вопрос, а зачем в одну хп напихали столько запросов? И прозрачности в нем никакой.

softwarer
Это лучший ответ, который я могу дать, не погружаясь в долгие и подробные объяснения "почему этот вопрос бессмысленен". То, что Вы спрашиваете, сродни старому анекдоту:


Я не просил Вас объяснять мне безсмысленность моего вопроса. А по поводу анекдота, настоящий профессор бы, таки объяснил физику процесса.
29 янв 07, 18:10    [3709502]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
Имхо этот та фича, которая дает некое синтаксическое удобство в простых случаях (меньше писать), но от которой надо решительно избавляться при разработке больших-и-сложных-программ.

На самом деле хотелось что бы и так и так было можно - можно же сейчас выкидывать результат и передавать скалярные параметры. Т.е. для разработки и просмотра промежуточных результатов или хода выполнения использовать непосредственный вывод, а при разработке клиентской части пользоваться параметрами. Например информацию из триггера очень удобно получать через непосредственный вывод(главное потом не забыть этот вывод убрать :)
29 янв 07, 18:15    [3709528]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
На самом деле хотелось что бы и так и так было можно - можно же сейчас выкидывать результат и передавать скалярные параметры. Т.е. для разработки и просмотра промежуточных результатов или хода выполнения использовать непосредственный вывод, а при разработке клиентской части пользоваться параметрами. Например информацию из триггера очень удобно получать через непосредственный вывод(главное потом не забыть этот вывод убрать :)

Я специально подчеркнул именно то, что недопустимо "в промышленных объемах" [давайте только не конкретизировать, сколько это будет в штуках и мегабайтах]. Здесь действуют законы Мерфи: если что-то может быть сделано плохо, то из [большой группы программистов] обязательно найдутся те, кто сделает плохо. Собственно, если переходить к реальности, то даже в группе из четырех человек мне однажды пришлось сказать парню примерно следующее: "если я еще раз увижу в твоем коде использование System.out.println - пойду к директору и поставлю вопрос о твоем служебном соответствии".

Для отладочных и прочих целей должны работать соответствующие инструменты, надежно, гарантированно не пересекающиеся с боевым кодом. "Для разработки" нужна функция типа out_cursor, которую в релизе можно будет отключить одним движением. И то, что Oracle не дает возможности писать плохой код, лично я привествую.
29 янв 07, 18:50    [3709705]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
SergSuper
На самом деле хотелось что бы и так и так было можно - можно же сейчас выкидывать результат и передавать скалярные параметры. Т.е. для разработки и просмотра промежуточных результатов или хода выполнения использовать непосредственный вывод, а при разработке клиентской части пользоваться параметрами. Например информацию из триггера очень удобно получать через непосредственный вывод(главное потом не забыть этот вывод убрать :)

Я специально подчеркнул именно то, что недопустимо "в промышленных объемах" [давайте только не конкретизировать, сколько это будет в штуках и мегабайтах]. Здесь действуют законы Мерфи: если что-то может быть сделано плохо, то из [большой группы программистов] обязательно найдутся те, кто сделает плохо. Собственно, если переходить к реальности, то даже в группе из четырех человек мне однажды пришлось сказать парню примерно следующее: "если я еще раз увижу в твоем коде использование System.out.println - пойду к директору и поставлю вопрос о твоем служебном соответствии".

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

На самом деле Вы преувеличиваете проблему - я ж фразу в шутку оставил, только для Вас. Отсутствие этой возможности всё равно даёт много других возможностей писать плохой код. А вещь удобная.
Ладно, я думаю с выводом из процедуры надо прекращать. Я во всяком случае на эту тему больше не пишу, по-моему все выяснили что могли выяснить.
29 янв 07, 19:21    [3709850]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
Т.е. Вы уверены, не проводя эксперимента в своей правоте, а я в подтверждении своей должен поставить эксперимент? Увольте. Я останусь при своей точке зрения.

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

pkarklin
softwarer
А Вы уверены, что он их различает?

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

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

Это разные объекты (даже незнающий программист "из общих соображений" вполне поймет, что VIEW и PROCEDURE - вовсе не обязательно одно и то же). Нет ничего удивительного, что у них разные требования. Впрочем, абсурдность этого Вашего аргумента особенно ярко видна в табличном виде:

VIEWPROCEDURE
SELECTcreate view as select ....create procedure as select ....
INSERTcreate view as insert ....create procedure as insert .....


Итого, если Вы полагаете страшной разницу между результатами команд в первой строке, вопрос: полагаете ли Вы столь же страшной разницу между результатами команд во второй строке? Почему?

pkarklin
Но это опять же Ваша точка зрения, а не не знающего SQL.

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

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

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

Действительно, сначала надо изучить SQL, затем PL\SQL.

Ага, знакомая песня. Итого, одни будут учить SQL, потом PL/SQL. А другие - не будут ничего учить, зато будут создавать программы, от которых уши дыбом встают.

pkarklin
Да еще не забыть, что такие хп только в пакетах можно создавать.

Плюньте в лицо тому, кто сказал Вам такую глупость. Бред какой-то, такое впечатление, что Вы придумываете на ходу.

pkarklin
И что будет "прозрачнее" для не знающего?

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

create function XXX return sys_refcursor as
  result sys_refcursor ;
begin
  ....
  return result ;
end ;

сможет сказать, что это функция, возвращающая результат неизвестного ему типа sys_refcursor. В случае MSSQL-ного

create procedure XXX as
  select .....

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

pkarklin
softwarer
С возвратом из хранимок в MSSQL вообще много забавного. Помнится, когда я только поставил его, попробовал примерно следующий подход...

Сразу оценил прозрачность, очевидность и прочую возможность программировать, зная только ANSI SQL. Кстати, а с каких пор ANSI SQL позволяет возвращать данные из ХП таким образом?

Странно, как Вам не пришла в голову "страшная и кощунственная мысль изучить используемый инструмент, т.е. заглянуть в хелп по инструкции CREATE PROC и EXEC.

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

Итого, надеюсь, мысль о том, что надо читать доки, считаем доказанной?

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

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

Кстати, раз уж пошла такая пьянка, сколь мне помнится, входящий в стандарт оператор INSERT в MSSQL можно делать в процедурах, но нельзя делать в функциях. Правильно ли я помню? Не смущает ли Вас этот диссонанс? Мне так кажется, между функцией и процедурой разница меньше, чем между процедурой и преставлением. Да, вот еще что. Почему это скалярную функцию в MSSQL требуется брать в begin-end скобки, а процедура запросто может обходиться без них? Неужели незнающему это будет прозрачно?

pkarklin
И неоднозначность русского языка позволяет Вам делать выводы, к которым Ваш опонет и не пришел. Ну, что ж - воля Ваша.

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

pkarklin
Спросил одного из них. Если Вы считаете, что я неправомерно задал вопрос Вам,

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

pkarklin
Хотя надеялся услышать от Вас, как от профессионала, пряиой ответ, а не очередную словесную эквилибристику.

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

Далее, я прямо ответил Вам: "Хм. С моей точки зрения - ничего. Пользуюсь. Что имели в виду джентльмены, спросите у них." Вы удовлетворены прямым ответом, или по-прежнему будете утверждать, что не получили его?

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

pkarklin
С таким же успехом, "дополнительными проблемами при коллективной разработке и особенно при сопровождении" м.б. следующее:

CREATE VIEW View1

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

  • В результате изменения тела объекта P1 изменилось поведение объекта P1
  • В результате изменения тела объекта P1 изменилось поведение объекта P2, прямо использующего P1
  • В результате изменения тела объекта P1 изменилось поведение объекта P2, косвенно использующего P1

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

    pkarklin
    softwarer
    И снова Вы уходите от темы как только Ваше же собственное утверждение начинает Вам мешать.

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


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

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

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

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

    pkarklin
    Сто не знающих программистов в жизни не додумаются написать такую инструкцию.
    Если уж программист дошел до такого уровня, то он по крайней мере заглянет в документацию.

    И снова Вы уходите от темы прозрачности. Прозрачность не означает "додумается написать", прозрачность означает в первую очередь "поймет написанное".

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

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

    pkarklin
    softwarer
    Фи. Грубо и некрасиво передергиваете. Код-то как раз прозрачен, думаю, ни у кого из присутствующих нет вопроса, что же он делает.

    У меня, как у одного из присутсвующих, возникает вопрос, а зачем в одну хп напихали столько запросов? И прозрачности в нем никакой.

    То есть Вы дошли до утверждения "раз MSSQL этого не умеет, значит это никому не нужно", я Вас правильно понял?

    Давайте так: спросите у авторов MSSQL, зачем они дали возможность возвращать из ХП несколько резалтсетов. А я воспользуюсь тем приемом, который Вы использовали чуть раньше, и спрошу у Вас: почему на том же форуме дельфы не раз и не два говорилось "вот MSSQL может вернуть сразу много резалтсетов как результат ХП, а XXXX - нет"? Почему это преимущество, ответьте как профессионал?

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

    pkarklin
    softwarer
    Это лучший ответ, который я могу дать, не погружаясь в долгие и подробные объяснения "почему этот вопрос бессмысленен". То, что Вы спрашиваете, сродни старому анекдоту:

    Я не просил Вас объяснять мне безсмысленность моего вопроса. А по поводу анекдота, настоящий профессор бы, таки объяснил физику процесса.

    Я и не объясняю Вам бессмысленность Вашего вопроса, я объясняю, почему другого ответа у меня нет, раз уж Вы не были полностью удовлетворены этим.
  • 29 янв 07, 19:59    [3709980]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67534
    Блог
    SergSuper
    На самом деле Вы преувеличиваете проблему - я ж фразу в шутку оставил,

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

    SergSuper
    Отсутствие этой возможности всё равно даёт много других возможностей писать плохой код.

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

    SergSuper
    А вещь удобная.

    Допустим (честно говоря, мне такое никогда не требовалось, поэтому не возьмусь однозначно соглашаться). Это значит, что ее надо корректно оформить. Скажем, я сделал себе процедуру отладочной печати, и знаю, что этот вопрос меня никогда волновать не будет. В то же время люди, пользующиеся "удобным" dbms_output.put_line рано или поздно нарвутся на то, что какой-нибудь ночной job подсчета дебиторки уже полгода как тихо падает из-за переполнения буфера вывода. Здесь то же самое - удобно, значит надо сделать так, чтобы было удобно и надежно. Как именно - в случае MSSQL сказать не возьмусь, недостаточно его знаю.
    29 янв 07, 20:05    [3710001]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Простите что анрегом
    Guest
    Не могу понять, почему возник такой спор - прозрачно ли в MS процедуры возвращают данные.
    Вообще-то процедура возвращает код возврата. Процедура может менять OUT параметры. И процедура может выполнить селект. Сколько угодно селектов. Только результаты селекта она не "возвращает". Результат отдается клиенту.

    Попробую пояснить небольшим примером, тем более, что речь зашла о программистах, не знающих SQL, и о том, насколько им будет ясен код ХП в MS.

    int myfunction(int a, int *b)
    {
        printf("Hello, world\n");
        ++*b;
    
        return 1;
    }
    

    На всякий случай поясню.
    Данная функция - аналог ХП, у которой есть два параметра, второй из них OUT. Функция возвращает конкретное значение, меняет второй параметр и выполняет некое действие, отправляя результат клиенту.

    Естественно, что в функции может быть сколько угодно printf(). Естественно, что если printf надо вызвать непосредственно в main - выглядеть он будет точно так же. Естественно, что если SELECT воткнуть не в ХП, а в триггер, то он точно так же проселектит.

    А, скажем, конструкция вида INSERT INTO @a EXEC MyProc есть не что иное, как перенаправление ввода-вывода.

    На мой взгляд, после такого объяснения любой адекватный программист сочтет, что селекты в ХП более чем прозрачны.
    Еще на мой взгляд - это очень удобно.

    Надеюсь, это внесет некую ясность для сторонников Oracle, потому что после прочтения топика у меня сложилось мнение, что они не совсем понимают механизма, "непрозрачность" которого доказывают.

    На всякий случай скажу, что оракла я, можно сказать, в глаза не видел. Но вроде бы про него ничего и не говорил, только про то, что знаю.
    29 янв 07, 22:13    [3710262]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Lepsik
    Member

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

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


    Мне кажется вы заблуждаетесь. Если человек работает с базой и не знает ANSI-SQL - то пользуется компонентами прямого доступа - тогда ваши оракловые фичи смысла не имеют.

    Если знает немного, то SELECT * FROM table - знает как миниумум и возврат процедурой рекорсета не вызывает удивления. Введение дополнительных фичей, а то как курсоры - дополнительная и не всегда понятная процедура. Человек хотел набор записей (2D массив вариантов, если мы говорим о программисте), а получает ссылку в неизвестно во что.

    softwarer

    возвращает. Если же показать ему аналогичную подпрограмму на PL/SQL - догадается, синтаксис там вполне традиционный.


    синтаксис традицинный, а что делать с дополнительной сущностью типа процедуры вряд ли сообразит. Ведь ее еще и создать придется. А в ней кроме знания ANSI SQL еще и курсорную специфику Оракла со всеми далеко идущими последствиями.

    softwarer

    pkarklin
    Я всего-навсего констатировал факт того, что такая же прозрачная конструкция, как возвращение результата их хп SELECTом в Oracle отсутствует.

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


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

    softwarer
    Пока что опять-таки получен один аргумент: ADO иначе не умеет.


    Учитывая что Windows стоит на подавляещем большинстве десктоп систем можем сделать тупой и простой вывод - механизм Оракла безнадежно устарел и без подпорок существовать не может.
    ODBC давно предиктед и в 64-битной версии OS не поддерживается.

    softwarer
    - существует ли в MSSQL возможность передать выборку из серверной ХП на клиент, используя как механизм передачи параметры подпрограммы и работая на клиенте с полученной выборкой нормальным для дельфы образом?


    вопрос - а зачем ? Есть естественный механизм [GetRows] in ADO - являющегося часть виндовс - возвращаюая тупой 2D массив данных. Из любой базы - MSSQL/Sybase/DB2/Oracle,....
    Никакой специки лазания по рекордсету знать не надо.
    30 янв 07, 00:07    [3710415]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    andy st
    Member

    Откуда:
    Сообщений: 906
    softwarer
    andy st
    про OLE DB провайдер это сильно. особенно если оракул крутится под линухом или чем-нибудь еще более экзотичным.

    Кстати... https://www.sql.ru/forum/actualthread.aspx?tid=389458

    и надо ставить смешанный режим авторизации, т.к. Windows NT Authentication Mode не тянет...
    некоторые админы с точки зрения безопасности в принципе не включают Mixed Mode авторизацию.
    30 янв 07, 05:39    [3710597]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    kennethr
    Member

    Откуда:
    Сообщений: 175
    softwarer
    В Oracle этой формой для ограничения доступа к объектам будут пользоваться только ламеры, желающие сделать "как привыкли".

    Расшифруйте почему, если не сложно. Я вижу здесь несколько проблем, например невозможно избежать мягких разборов. Но если есть желание создать пользователя с очень узкими правами, почему не использовать такой подход?
    30 янв 07, 06:47    [3710617]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    kennethr
    Member

    Откуда:
    Сообщений: 175
    Простите что анрегом
    На мой взгляд, после такого объяснения любой адекватный программист сочтет, что селекты в ХП более чем прозрачны.

    о прозрачности такого подхода
    30 янв 07, 07:49    [3710683]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    kennethr
    Member

    Откуда:
    Сообщений: 175
    Sorry. о прозрачности такого подхода
    30 янв 07, 07:55    [3710689]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Bogdanov Andrey
    Member

    Откуда: Да уже и сам не знаю...
    Сообщений: 2203
    Простите что анрегом

    Попробую пояснить небольшим примером, тем более, что речь зашла о программистах, не знающих SQL, и о том, насколько им будет ясен код ХП в MS.

    int myfunction(int a, int *b)
    {
        printf("Hello, world\n");
        ++*b;
    
        return 1;
    }
    

    На всякий случай поясню.
    Данная функция - аналог ХП, у которой есть два параметра, второй из них OUT. Функция возвращает конкретное значение, меняет второй параметр и выполняет некое действие, отправляя результат клиенту.

    Естественно, что в функции может быть сколько угодно printf(). Естественно, что если printf надо вызвать непосредственно в main - выглядеть он будет точно так же. Естественно, что если SELECT воткнуть не в ХП, а в триггер, то он точно так же проселектит.


    Своим примером вы очень "уронили" MSSQL в моих глазах.

    Для начала замечу, что ваш пример совсем не прозрачен. Особенно для программистов мало писавших на C. Где программист должен искать этот самый "Hello" после выполнения вашей программы? А что будет в случае неконсольного приложения? А уж для распределенных систем это вообще может стать неразрешимой загадкой.

    Таким образом я согласен рассматривать printf лишь как средство отладки (кстати не слишком удобное), которое ни в коем случае не должно встречаться в промышленном коде (что "отрывают" за отладку в промышленном коде softwarer уже сообщал). Я так понял, что запросы внутри ХП вы ставите на одну полку с отладочным printf. А значит тем 99 процентам программистов MSSQL, которые используют select в промышленном коде, можно смело влепить служебное несоответствие.
    Я правильно понял вашу мысль?
    30 янв 07, 09:10    [3710850]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    AAron
    Member

    Откуда: Москва
    Сообщений: 4324
    Господа-противники запросов в тексте процедур.
    Ответьте на вопрос, как вы отлаживаете процедуру, выполняющую, например, такие действия
    CREATE OR REPLACE PROCEDURE test1 ()
    p1 integer
    ...
    --представьте здесь любой запрос с достаточным количеством джойнов и условий, параметризованный 3-4-5 параметрами
    INSERT INTO tbl1 (some_fields)
    SELECT some_fields FROM tbl2
    WHERE tbl2.id = p1
    ...
    
    условие такое интерфейс вызова ХП не должен меняться (никаких OUT ref-cursor'ов), дебаг не должен усложнять код (никаких ref-cursor'ов во внешнюю процедуру, которая "распечатает" выборку).

    Объясните свои подходы к таким задачам, и скорее всего вопросы исчезнут.
    30 янв 07, 10:28    [3711246]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67534
    Блог
    Простите что анрегом
    Не могу понять, почему возник такой спор - прозрачно ли в MS процедуры возвращают данные.

    Вообще-то процедура возвращает код возврата. Процедура может менять OUT параметры. И процедура может выполнить селект. Сколько угодно селектов. Только результаты селекта она не "возвращает". Результат отдается клиенту.

    Во-первых, результат она таки "возвращает", см. про INSERT EXEC. Если точнее, она складывает результаты селекта в некий глобальный буфер, а некоторые операции читают этот буфер. В частности, если вызов инициирован с клиента, его читает клиент.

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

    Простите что анрегом
    А, скажем, конструкция вида INSERT INTO @a EXEC MyProc есть не что иное, как перенаправление ввода-вывода.

    Есть определенная аналогия.

    Простите что анрегом
    На мой взгляд, после такого объяснения любой адекватный программист сочтет, что селекты в ХП более чем прозрачны.



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

    Простите что анрегом
    Еще на мой взгляд - это очень удобно.

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

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

    Признаться, сложилось впечатление, что Вы несколько поспешно читали топик.

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

    Здесь безусловно никаких претензий. Вообще то письмо, на которое я отвечаю, оставило весьма приятное впечатление о Вас как о собеседнике.
    30 янв 07, 10:44    [3711375]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67534
    Блог
    Lepsik
    Мне кажется вы заблуждаетесь. Если человек работает с базой и не знает ANSI-SQL - то пользуется компонентами прямого доступа - тогда ваши оракловые фичи смысла не имеют.

    Во-первых, совершенно не понял этой фразы.

    Но во-вторых, суть не в этом. Если с БД работает человек, который ничего не знает, в этом безусловно нет ничего хорошего, и глубоко обсуждать это не стоит. Вся эта большая тема появилась из-за того, что Павел назвал mssql-ный подход "прозрачным", причем контекст подразумевал "более прозрачным чем оракловый".

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

    Lepsik
    Если знает немного, то SELECT * FROM table - знает как миниумум и возврат процедурой рекорсета не вызывает удивления.

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

    Lepsik
    Введение дополнительных фичей, а то как курсоры - дополнительная и не всегда понятная процедура.

    Дополнительная и не всегда понятная. Но явная. Повторюсь: если программист видит код

    declare
      result sys_refcursor ;
    begin
      ...
      return result ;
    end ;

    он именно что без всяких дополнительных знаний, даже не зная, что такое селект, поймет, что это функция, возвращающая "нечто типа sys_refcursor". И разберется при необходимости, что это такое. Видя обычную процедуру, начинающуюся с begin, заканчивающуюся end и без следов какого-либо return внутри, он вряд ли поймет, что процедура что-то возвращает.

    Lepsik
    синтаксис традицинный, а что делать с дополнительной сущностью типа процедуры вряд ли сообразит. Ведь ее еще и создать придется. А в ней кроме знания ANSI SQL еще и курсорную специфику Оракла со всеми далеко идущими последствиями.

    Хм. Я еще раз публикую призыв придерживаться темы. Если мы говорим о прозрачности - давайте говорить о прозрачности. Если Вы хотите поднять тему "T-SQL легче в освоении" - давайте поднимем ее. Но отдельно.

    Lepsik
    вы подменяете понятия. возврат укзателя на выдделенный в памяти массив структур - это совсем не одно и тоже что и передача указателя на непонятный "для рядового WinAPI (коего вы видимо имели виду) интерфейс.

    1. Вы пардон несете какой-то бред, никак не связанный с тем, на что отвечаете. Какой WinAPI? Вы о чем вообще?

    Lepsik
    softwarer
    Пока что опять-таки получен один аргумент: ADO иначе не умеет.


    Учитывая что Windows стоит на подавляещем большинстве десктоп систем можем сделать тупой и простой вывод - механизм Оракла безнадежно устарел и без подпорок существовать не может.
    ODBC давно предиктед и в 64-битной версии OS не поддерживается.

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

    Lepsik
    softwarer
    - существует ли в MSSQL возможность передать выборку из серверной ХП на клиент, используя как механизм передачи параметры подпрограммы и работая на клиенте с полученной выборкой нормальным для дельфы образом?


    вопрос - а зачем ?

    (Терпеливо) потому что недостатки "естественного механизма" объяснены ранее, там, где Вы видимо поленились читать.

    Пардон, но прекращаю общение с Вами по крайней мере до тех пор, пока Вы со своей стороны не поднимете уровень обсуждения.
    30 янв 07, 11:02    [3711546]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67534
    Блог
    andy st
    и надо ставить смешанный режим авторизации, т.к. Windows NT Authentication Mode не тянет... некоторые админы с точки зрения безопасности в принципе не включают Mixed Mode авторизацию.

    Признаться, я в этом не ориентируюсь и никак не могу прокомментировать. И? Я, собственно, привел пример того, что возможен даже такой изврат, как работа ODBC и TDS непосредственно под Linux, хотя сам вряд ли стал бы делать так, предпочитая более прямые пути.
    30 янв 07, 11:04    [3711568]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

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

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

    AAron
    дебаг не должен усложнять код (никаких ref-cursor'ов во внешнюю процедуру, которая "распечатает" выборку).

    Так-так-так. А нельзя ли этот момент поподробнее? Скажем, взяв процедуру выше - как Вы собираетесь отлаживать ее с этим ограничением? Я просто не очень понял, что Вы здесь имеете в виду под "усложнением" и "неусложнением" кода.
    30 янв 07, 11:18    [3711675]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Bogdanov Andrey
    Member

    Откуда: Да уже и сам не знаю...
    Сообщений: 2203
    AAron
    Господа-противники запросов в тексте процедур.
    Ответьте на вопрос, как вы отлаживаете процедуру, выполняющую, например, такие действия


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

    AAron

    Объясните свои подходы к таким задачам, и скорее всего вопросы исчезнут.

    В Oracle для подобной трассировки я создам процедуру, которая получая на входе текст запроса скинет его результат (отформатировав) в dbms_output буфер. Естественно это несколько менее удобно из-за отсутствия неявного связывания переменных, но вполне достаточно. Кстати, не помню чтобы у меня возникала необходимость подобной трассировки. Мне всегда хватало вывода значений пары переменных.
    Но!
    Я не буду создавать такую процедуру на рабочей базе. И все, кто попытается воспользоваться ею в промышленном коде будут "побиты".
    30 янв 07, 11:22    [3711708]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 23   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить