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

Откуда: SPb
Сообщений: 5488
DimaR
pkarklin

Так:

теже яйца, но
почемуто у mssql-щиков, бытует мнение, что в оракле это намного сложнее, и не удобно

не то что сложно - более процедурно
26 янв 07, 14:19    [3699377]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
DimaR
почемуто у mssql-щиков, бытует мнение, что в оракле это намного сложнее, и не удобно
не то что сложно - более процедурно
Эээ, а почему если через временную таблицу так сразу и более процедурно ?

Сообщение было отредактировано: 26 янв 07, 15:44
26 янв 07, 14:33    [3699514]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Если не ошибаюсь, проблема в том, что этот курсор не может быть передан на клиента как рекордсет. В той теме вроде бы это упоминалось; суть в том, что в Oracle мы делаем ref cursor (или несколько), присваиваем ему какое-то значение, можем вернуть его в другую хранимку, можем вернуть на клиента, можем фетчить их в любом порядке.


MS SQL:

1. Мы можем объявить переменную типа курсор:

DECLARE @Cur CURSOR

2. Сопоставить ей курсор:

SET @Cur = CURSOR LOCAL FAST_FORWARD FOR SELECT au_id FROM authors

3. Дальше можем:
3.1. Передать его в хп для работы
3.2. фечить его с клиента

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

В дополнение к этому MS SQL содержит ряд системных хп:

sp_cursoropen defines the SQL statement to be associated with the cursor and the cursor options, then populates the cursor.
sp_cursorfetch fetches a row or block of rows from the cursor.
sp_cursorclose closes and deallocates the cursor.
sp_cursoroption is used to set various cursor options.
sp_cursor is used to request positioned updates.
sp_cursorprepare compiles the Transact-SQL statement or batch associated with a cursor into an execution plan but does not create the cursor.
sp_cursorexecute creates and populates a cursor from the execution plan created by sp_cursorprepare.
sp_cursorunprepare discards the execution plan from sp_cursorprepare.

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

Ну, и, чего не умеет Oracle, так это просто вернуть набор данных.

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


Считаю тему с NOCOUNT закрытой. ;)
26 янв 07, 14:36    [3699545]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
kennethr
Это возможно уже сейчас или возможно потенциально?

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

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

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

Какая разница? "Такая схема" влияет лишь на то, что косметически в базе станет меньше инвалидных объектов, но больше шансов нарваться на ошибку типа "body is invalid" во время выполнения. На технологии разработки изменение никак не повлияет.

Не понял, что Вы называете локальными процедурами (вложенные, что ли?), да и вообще не очень понял смысла фразы в целом. Слова "спрашивая других разработчиков" для меня звучат... сомнительно с точки зрения правильной организации дел.

kennethr
Насколько я понял, пока у MSSQL все свалено в кучу. Это так?

Это вопрос не ко мне.
26 янв 07, 14:37    [3699551]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper
Приходилось, я и с 4-й работал
Вот в 6.5 то как раз лучше было - проверялись поля временных таблиц


В 6.5 не было deffered name resolution, и чтобы создать хп, которая бы обрабатывала данные во временной табличке, которые на самом деле будет создана и заполнена до ее вызова, приходилось создавать такую темповую таблицу в этой же сессии.
26 янв 07, 14:39    [3699581]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
мастер утешать
в MS-SQL-2005 есть такая "фича" как схемы для "логической группировки" объектов БД (в 2000-м, к сожалению, эти схемы вырождены до уровня "создателя/владельца" объекта):


Основное назначение введенных в 2005 схем - сепарация пользователей от владения объектами, как это было до этого.
26 янв 07, 14:52    [3699682]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
1. Мы можем объявить переменную типа курсор:
3. Дальше можем:
3.1. Передать его в хп для работы
3.2. фечить его с клиента

OK. Значит, осталось понять, почему этот способ не является доминирующим. Подозреваю, у него есть какие-то недостатки. В частности я не увидел прямого ответа на вопрос: можно ли без дополнительных усилий запитать из такого курсора например DBGrid?

pkarklin
Ну, и, чего не умеет Oracle, так это просто вернуть набор данных.

Хм. Иногда такое ощущение, что разговор идет с магнитофоном.

Oracle умеет "просто и правильно вернуть набор данных". Никакой другой способ "простого возвращения данных" ему не нужен, особенно "просто и неправильно".
26 янв 07, 15:05    [3699794]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
Основное назначение введенных в 2005 схем - сепарация пользователей от владения объектами, как это было до этого.

Это правильная мысль. Schema и account должны быть разными понятиями.
26 янв 07, 15:06    [3699800]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

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

Ошибся. Я подумал вы говорите о подмене хранимыми процедурами MSSQL функционала пакетов Oracle.
"спрашивая других разработчиков" это только метафора. Обычно используется такое правило: не менять/удалять заголовок процедуры. Конечно так поступают не всегда.
26 янв 07, 15:10    [3699831]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Хм. Иногда такое ощущение, что разговор идет с магнитофоном.

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


Ну, давайте не будем глумиться. :) Вы прекрасно понимаете, что я (занимающийся MS SQL) имею ввиду под просто и правильно:

CREATE     PROCEDURE usp_DeptsPDBPrimPlanNew 
  @Period datetime, -- период
  @Manuf int        -- выбраный в приложении цех
AS
--ПК "Учет в цехах". Модуль "ПДБ"
--Применяемость узлов\деталей на план 
--Права: 
--  Цех-common    = [Execute];
--  Цех-БТЗ       = [];
--  Цех-ПДБ       = [Execute];
--  Цех-Склад     = [];
--  Цех-Бухгалтер = [];
--  Цех-Экономист = []; 

Set Nocount on 

-- план - график ПДО --
Create table #tblPlanGraph (
  colAmount numeric(19, 4) default (0) , 
  colProductID int not null, 
  colFact numeric(19, 4) default (0), 
  colDepartmentID int not null 
                                            )
---- 
----
Insert Into #tblPlanGraph  
  (colAmount, colProductID, colFact, colDepartmentID) 
SELECT colAmount = sum(colAmount), 
             colProductID, 
             colFact = sum(colFact), 
             colDepartmentID
 FROM tblPlanPDO nolock
 WHERE
  ((colPeriod = @Period and colAmount > 0) 
  or  (colPeriod = @Period and colFact > 0)) 
  and colDepartmentUP is null
 
 GROUP BY  colProductID, 
                      colDepartmentID
----
----
-- отбор узлов (деталей) изгот. в выбранном цехе без повтора заходов -- 
Create table #tblProductsPIN (
  colProductID1 int not null, 
  colPIN varchar(50) null, 
  Amount float default (0), 
  colProductInID int not null, 
  colDepartmentID int not null, 
  colImplementCode int not null 
                              ) 
INSERT INTO #tblProductsPIN (colProductID1, colPIN, Amount, 
                     colProductInID, colDepartmentID, colImplementCode) 
SELECT Distinct
  tblContentsByOrders.colProductID1, 
  tblContentsByOrders.colPIN, 
  Amount = tblContentsByOrders.colAmount,
  tblContentsByOrders.colProductInID, 
  colDepartmentID = tblRoutesContents.colProdManufacturer, 
  tblProdNomenclature.colImplementCode 
FROM
  tblContentsByOrders 
  INNER JOIN 
  ( SELECT DISTINCT
                 colProductID, colDepartmentID 
              FROM tblPlanPDO  
              WHERE
                ((colPeriod = @Period and colAmount > 0) 
                or  (colPeriod = @Period and colFact > 0)) 
                and colDepartmentUP is null 
                                                                             ) as tblGraph ON
  tblContentsByOrders.colProductID1 = tblGraph.colProductID
  INNER JOIN tblRoutesContents  
   ON tblContentsByOrders.colPIN = tblRoutesContents.colPIN and
    tblGraph.colDepartmentID = tblRoutesContents.colProdManufacturer
  INNER JOIN tblProdNomenclature  
   On tblContentsByOrders.colProductInID = tblProdNomenclature.colProductID
WHERE (tblRoutesContents.colManufacturer = @Manuf)
OPTION (FORCE ORDER)  

-- кол-во узлов (деталей) изгот. в выбранном цехе  --
SELECT
  #tblProductsPIN.colProductID1, 
  colAmount = max(#tblPlanGraph.colAmount), 
  colFact = max(#tblPlanGraph.colFact), 
  Amount = sum(#tblProductsPIN.Amount),
  colProductInID = (#tblProductsPIN.colProductInID), 
  colDepartmentID = #tblProductsPIN.colDepartmentID, 
  colImplementCode = min(#tblProductsPIN.colImplementCode) 
INTO #tblProducts
FROM #tblProductsPIN 
  Inner Join #tblPlanGraph 
   On #tblProductsPIN.colProductID1 = #tblPlanGraph.colProductID 
     And  #tblProductsPIN.colDepartmentID = #tblPlanGraph.colDepartmentID 

GROUP BY
  #tblProductsPIN.colProductID1, 
  #tblProductsPIN.colDepartmentID, 
  #tblProductsPIN.colProductInID 

-- изделие для учета комплектовки и экспортного исполнения -- 

Select colProductInID, 
    colProdName = max(usv_ProductsListW00.ProductName), 
    colAmount = Sum(Amount*colAmount), 
    colFact = Sum(Amount*colFact), 
    colImplementCode = colImplementCode 
From #tblProducts  Inner Join usv_ProductsListW00 
   On #tblProducts.colProductInID = usv_ProductsListW00.ProductID  

Group By colProductInID, colImplementCode 
Order By  colImplementCode, 2 
26 янв 07, 15:17    [3699885]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

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


Потому что доминирует другой, который не использует курсоры. Из ограничений: DBGridу нужен набор, поддерживающий закладки. Если использовать родные компоненты ADO, то в их реализации серверный курсор не поддерживает оных.
26 янв 07, 15:21    [3699925]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
мастер утешать
Guest
pkarklin
...Основное назначение введенных в 2005 схем - сепарация пользователей от владения объектами, как это было до этого.


Я бы не стал так само-очевидно отвечать "за всю Одессу"...
Да, в до-2005-х версиях понятие "схема" жестко было привязано к создателю/владельцу объекта, который, кроме как "пользователем" никем иным быть и не мог.
В 2005-м же, ИМХО, не пользователей от-"сепарировали" от владения объектами (т.о. получается, что "владеть" объектами заставили схемы), а вынесли само понятие "владелец" за скобки отношений к объектам БД (что в общем виде, наверное, более правильно с точки зрения стандартов).

BOL

...
In SQL Server 2000, database users and schemas are implicitly connected. Every database user is the owner of a schema that has the same name as the user.
...
In SQL Server 2005, schemas exist independently of the database user that creates them... And objects can be created in schemas with user-friendly names that clearly indicate their function...

Болдом я выделил существенные (на мой взгляд) отличия, которые не привязывают схемы к отношениям "владения" объектами, а дают возможность разработчику и/или администратору самостоятельно выбирать тот уровень логического обобщения, который он захочет реализовать при помощи схем...
26 янв 07, 15:23    [3699945]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
Ну, давайте не будем глумиться. :) Вы прекрасно понимаете, что я (занимающийся MS SQL) имею ввиду под просто и правильно:

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

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

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

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

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

О том, какие недостатки мешают повсеместно применять именованные курсоры для возврата рекордсетов, по-прежнему хотелось бы услышать.
26 янв 07, 15:27    [3699973]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
мастер утешать
В 2005-м же, ИМХО, не пользователей от-"сепарировали" от владения объектами (т.о. получается, что "владеть" объектами заставили схемы)


Именно так и сделано. Вы не удалите схему, если в ней есть объекты.
26 янв 07, 15:29    [3699977]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

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


К сожалению, я сегодня ограничен во времени. Могу повторить только то, что уже говорил, а Вы не хотите слышать. Есть ДРУГОЙ способ (обычный SELECT в хп), который является повсеместно применим при работе с MS SQL. Использование курсоров для обмена данным - редкий, но применимый способ. О невозможности использования такого подхода в частности в DBGrid я сказал.

За сим на сегодня и выходные разрешите откланяться. Вернусть к обсуждению в понедельник. Хочеться немного отдохнуть подальше от информационных технологий.
26 янв 07, 15:33    [3700013]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
softwarer
Значит, осталось понять, почему этот способ не является доминирующим. Подозреваю, у него есть какие-то недостатки.

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

Масло масляное.

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

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

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

    pkarklin
    Из ограничений: DBGridу нужен набор, поддерживающий закладки. Если использовать родные компоненты ADO, то в их реализации серверный курсор не поддерживает оных.

    Правильно ли я понимаю, что дописать поддержку требуемой функциональности будет нетривиальной задачей? Если так, ответ на первый вопрос отчасти проясняется.
  • 26 янв 07, 15:34    [3700019]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Yo.!
    Guest
    pkarklin

    Разница все-таки есть:

    A new implementation of read committed isolation that uses row versioning when the READ_COMMITTED_SNAPSHOT database option is ON.

    A new isolation level, snapshot, that is enabled when the ALLOW_SNAPSHOT_ISOLATION database option is ON.

    ...

    Read committed isolation using row versioning provides statement-level read consistency. As each statement within the transaction executes, a new data snapshot is taken and remains consistent for each statement until the statement finishes execution.


    Snapshot isolation provides transaction-level read consistency. A data snapshot is taken when the snapshot transaction starts, and remains consistent for the duration of the transaction.


    Я не зря поставил отключать в кавычки. Естественно, что применение хинта не избавляет от поддержки версий в tempdb, зато позволяет накладывать разделяемые блокировки. Это м.б. важно для унаследованных приложений, которые расчитаны на такие блокировки.

    изначально вы говорили "Причем tempdb используется по минимому (не путать с опцией ALLOW_SNAPSHOT_ISOLATION для поддержки уровня изоляции SNAPSHOT).", а это не так. с точки зрения i/o на tempdb никакой разницы нет, все блокировочные транзакции обязаны плодить версии и нагружать tempdb.
    26 янв 07, 15:48    [3700111]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67525
    Блог
    pkarklin
    Могу повторить только то, что уже говорил, а Вы не хотите слышать. Есть ДРУГОЙ способ (обычный SELECT в хп), который является повсеместно применим при работе с MS SQL.

    Павел, я не "не хочу слышать", а "хочу услышать что-то логичное".

    Вы упорно высказываете сожаление на тему "Oracle не умеет". Именно это мы сейчас обсуждаем. Единственный аргумент, который от Вас прозвучал - "повсеместно применим при работе с MSSQL". С моей точки зрения, это крайне слабый аргумент даже сам по себе, хотя для облегчения миграции с MSSQL на Oracle может быть и стоило бы сделать. Однако, у этого способа есть очевидный недостаток по сравнению с имеющимся в Oracle. В связи с этим я пытаюсь выяснить: а что в этом способе хорошего, лучшего? Пока что опять-таки получен один аргумент: ADO иначе не умеет. В том, что касается работы с Oracle, это снова крайне слабый аргумент, поскольку естественный и правильный вывод из него "ну и в задницу этот ADO, надо использовать нормальные библиотеки". Тем более, этот момент является лишь одним из длинной серии недостатков связки ADO+Oracle.

    Напомню, в этой теме мы ставим "плюсы" и "минусы". Пока что я не вижу оснований ставить минус ораклу и/или плюс мсскл-ю за наличие упомянутой Вами фичи. Если смотреть именно с позиций плюсов-минусов, пока видим ситуацию "у Oracle есть единственный способ, лишенный недостатков" против "у MSSQL есть два способа, каждый с собственным недостатком".

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

    P.S. По Вашим последним письмам складывается впечатление, что Вы слегка подзабыли обсуждаемую тему. Напомню, я нисколько не нападаю на MSSQL из-за того, что там "работают не по-оракловому". Я исключительно спрашиваю хоть чем-нибудь аргументированное обоснование точки зрения "недостатком оракла является отсутствие поддержки не самого удачного подхода, повсеместного в mssql".
    26 янв 07, 15:54    [3700168]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    мастер утешать
    Guest
    pkarklin
    ... Вы не удалите схему, если в ней есть объекты.


    Отличный пример тренировки дедуктивного мышления!!!
    Вы не удалите роль, если в ней есть пользователи, отсюда вывод - роли "владеют" пользователями...
    Вы не удалите таблицу, если в ней есть ссылки FK на другую таблицу, отсюда вывод - подчиненные таблицы "владеют" мастер-таблицами...
    Вы не удалите много чего, если есть что-то другое, зависимое от этого "чего", отсюда вывод - все "владеют" всем...
    26 янв 07, 16:00    [3700214]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    Gluk (Kazan)
    SergSuper
    DimaR
    почемуто у mssql-щиков, бытует мнение, что в оракле это намного сложнее, и не удобно
    не то что сложно - более процедурно
    Эээ, а почему если через временную таблицу так сразу и более процедурно ?

    я имел в виду что на Оракле надо писать несколько чужеродные для SQL присвоения j:=2;k:=, потом выполнять опять же не SQLкоманду записи в поток pipe row(i) (пардон, но не знаю правильных терминов)
    на mssql же всё делается родными командами insert

    кстати тот же пример с простыми числами можно сделать и с одним циклом
    CREATE    FUNCTION sn(@cnt int)
    RETURNS @seq TABLE (i int )
    AS
    BEGIN
    declare @n int
    set @n=2
    while 2*2=4
    begin
      insert @seq select @n
      set @n=@n+1
      if @n>@cnt break
    end
    
    delete s
      from @seq s, @seq d
      where d.i<>s.i and s.i%d.i=0 and d.i<sqrt(s.i)
    RETURN
    END
    а я так понимаю в Оракле декларативные операции с потоком сделать нельзя
    26 янв 07, 16:03    [3700240]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Gluk (Kazan)
    Member

    Откуда:
    Сообщений: 9365
    SergSuper
    я имел в виду что на Оракле надо писать несколько чужеродные для SQL присвоения j:=2;k:=, потом выполнять опять же не SQLкоманду записи в поток pipe row(i) (пардон, но не знаю правильных терминов)
    на mssql же всё делается родными командами insert


    А что, операторы set и сравнения в if-ах таки перестали быть чужеродными SQL-ю ???
    26 янв 07, 16:08    [3700283]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Gluk (Kazan)
    Member

    Откуда:
    Сообщений: 9365
    SergSuper

    а я так понимаю в Оракле декларативные операции с потоком сделать нельзя


    pipelined это не поток, это способ отдачи данных так, чтобы оптимизатор думал что это ТАБЛИЦА
    со всеми вытекающими деккларотивностями
    26 янв 07, 16:10    [3700298]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67525
    Блог
    SergSuper
    я имел в виду что на Оракле надо писать несколько чужеродные для SQL присвоения j:=2;k:=,

    Хм. SET @j=2 чем-то "менее чужеродно", нежели j:=2? Имхо оно лишь "более громоздко".

    SergSuper
    потом выполнять опять же не SQLкоманду записи в поток pipe row(i) (пардон, но не знаю правильных терминов) на mssql же всё делается родными командами insert

    Эта "родная команда" употребляется в процедуре, и содержащий ее код "менее процедурным" не становится.

    SergSuper
    а я так понимаю в Оракле декларативные операции с потоком сделать нельзя

    Хм. Не уверен в Вашем понимании ситуации, поэтому общий рассказ на тему.

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

    Специфическим видом табличных функций являются конвейерные табличные функции. Их особенность в том, что они работают не по схеме "вычислил - отдал результат", а по схеме "вычислил часть результата - отдал - вычислил следующую часть результата - отдал - ....". "Исправить уже отданную ранее часть результата" при их использовании, разумеется, невозможно - тот уже не только "отдан", но и "употреблен в дело".
    26 янв 07, 16:22    [3700407]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    Gluk (Kazan)
    SergSuper
    я имел в виду что на Оракле надо писать несколько чужеродные для SQL присвоения j:=2;k:=, потом выполнять опять же не SQLкоманду записи в поток pipe row(i) (пардон, но не знаю правильных терминов)
    на mssql же всё делается родными командами insert


    А что, операторы set и сравнения в if-ах таки перестали быть чужеродными SQL-ю ???

    да, тут был не прав. Но вот pipe row(i) - всё-таки не insert
    Gluk (Kazan)

    pipelined это не поток, это способ отдачи данных так, чтобы оптимизатор думал что это ТАБЛИЦА
    со всеми вытекающими деккларотивностями

    вот способ и не нравится
    но вот вы(оракловцы) в функции сделали pipe row(i) - у всё, добраться до этой записи из функции у вас возможности нет
    а "мы" вставляем записи как в таблицу и может работать с нами как с таблицей

    а вообще (сейчас мне в голову пришло) наверное это больше эстетические расхождения
    был бы синтаксис вместо pipe row(i) какой-нибудь insert result values(i) - уже выглядело бы декларативней
    26 янв 07, 16:24    [3700419]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    мастер утешать
    Guest
    softwarer
    ...спрашиваю хоть чем-нибудь аргументированное обоснование точки зрения "недостатком оракла является отсутствие поддержки не самого удачного подхода, повсеместного в mssql".


    Может быть я не так "въехал в тему", но - почему вы считаете возврат resultset-а (или множества resultset-ов) из хранимой процедуры в качестве "естественной реакции" на SELECT ... (или множества SELECT-ов) в теле этой процедуры "не самым удачным подходом"?
    Только потому, что "DBGridу нужен набор, поддерживающий закладки"?
    Так вашими же словами можно и ответить - "ну и в задницу этот DBGrid, надо использовать нормальные библиотеки"...
    Или потому, что "серверные курсоры" - какая-то "священная корова" Oracle, от которой нельзя отказаться в других серверах БД...
    (в т.н. "мире MS-SQL-Server" давно известна "любовь" разработчиков к серверным курсорам).
    26 янв 07, 16:27    [3700456]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 23   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить