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

Откуда:
Сообщений: 899
softwarer
andy st
Вашими бы устами... :)
поставим, и получим еще 3 точки возможного сбоя.
хорошее решение в "тепличных условиях", а в условиях производства (которое я наблюдаю) система будет мертворожденная. к сожалению.

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

каюсь...
Просто у меня есть дурная привычка не заниматься чистым (теоретическим) проектированием, а еще и пытаться представить эксплуатационную пригодность того, что напроектируем.

softwarer

andy st
не угадали. :)
ситуация, возможно, еще любопытнее - провайдера писали даже не к СУБД.

Мне смутно вспоминается, что "провайдер не к СУБД" - это стандартный пример из MSDN или какой-то другой микрософтовской доки по OLE DB.

а разве есть еще варианты, откуда еще можно взять доку по написанию провайдеров?
31 янв 07, 12:34    [3718630]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
MGR
andy st

Этот скрипт загружает из всех xls-файлов в заданной папке содержимое Лист1 в таблицы.
таблицы создаются автоматом и имеют имя = имени файла.

А если имена листов - Sheet1? А если - "1"?
Как мне получить именно первый лист, независимо от его имени?

возможность есть через служебные хранимки, кода будет больше. подробнее - BOL.
а в данном случае было сделано допущение, что все файлы будут иметь "Лист1", на котором и будет вестись запись данных.
31 янв 07, 12:40    [3718672]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)
У автономных транзакций МНОГО осмысленных применений, в том числе выполнение DDL там где без них его делать нельзя. Просто надо ЗАДУМЫВАТЬСЯ о последствиях таких применений.

такая реализация DDL - это число специфика oracle.
и задумчивость о последствиях после его применения тоже...
31 янв 07, 12:45    [3718713]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
MGR
Member

Откуда:
Сообщений: 536
andy st

возможность есть через служебные хранимки, кода будет больше. подробнее - BOL.
а в данном случае было сделано допущение, что все файлы будут иметь "Лист1", на котором и будет вестись запись данных.


Не надо меня эртеэфэмить - я не нашёл этого в BOL, а нужно было. У некоторых клиентов стоит русский офис, у некоторых - английский.
31 янв 07, 12:50    [3718759]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
задумчивость о последствиях после его применения тоже...


задумываться о последствиях ПОЛЕЗНО независимо от выбранной платформы
31 янв 07, 12:59    [3718844]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

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

andy st
может тогда вообще не стоит утверждать?

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

некоторые некорректные (из уважения к моему склерозу):
1. человеку, не знающему sql привычнее увидеть вариант возврата данных курсором от oracle, чем вариант от mssql
2. 50% систем, в которых критична кроссплатформенность...
softwarer

andy st
softwarer

Второй - не затруднит ли Вас подсчитать, сколько я сделал в этом топике утверждений об MSSQL, в скольких из них допустил фактическую ошибку, сколько утверждений об Oracle делали Вы, или например pkarklin, и в скольких из них фиксировались фактические ошибки?

я выше написал пример с openrowset-ом.
если у Вас етсь время и вас не затруднит - приведите аналог для oracle.
если удастся - это моя фактическая ошибка. если нет - Ваша

Вы, простите, какую траву курите? Какое отношение Ваши примеры имеют к моему "я сделал в этом топике утверждений об MSSQL"? Вы вообще читаете, на что отвечаете, или к Вам следует отнестись как к Lepsik-у?

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

softwarer

Не знаю. Честно говоря, хотелось бы побеседовать хоть с одним толковым MSSQL-щиком, грамотным и логичным. За всю жизнь я встретил одного такого - Sinclair с rsdn.ru - но он, к сожалению, в последнее время почти не пишет.

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

softwarer

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

ок. я признаю, что ошибся и Вы такого не писали (честно говоря мне уже по барабану).
дык пример то будет?

softwarer

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

а толщину мерять не будем?

softwarer

andy st
3. отвечаете Вы мне по собственной инициативе

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

ОК

softwarer

andy st
как можно чаще подписывайте "имхо" или русскоязычныый аналог, плз.

Забавно смотрится после того, как Вы утверждали объективно ложную вещь без всякого имхо.

признаю. я лгал. Вам стало легче? я рад в любом случае.
но Вы то прекратите словоблудие?

softwarer

andy st
а есть принципиальное отличие рекордсетов из хранимок от применения printf ???
оба механизма могут применяться как при отладке, так и при обработке данных.

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

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

softwarer

andy st
softwarer

andy st
вот только разработчики mssql то и не в курсе, что это дыра.

Угу. А еще недавно они не знали про исключения

ага. исправились. теперь пользуюсь.

То есть в этом случае признали, что существует нечто более совершенное? Или "только вместе с генеральной линией партии", то есть с появлением исключений в MSSQL?

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

andy st

хотя и существует мнение (не мое), что исключения - зло и расслабляют программистов.

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

Вы обрабатываете все возможные варианты ошибок при возникновении исключения?
или тупой откат?
31 янв 07, 13:08    [3718901]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)
andy st
получается, что вменяемого аналога не существует?
p.s.: т.е. если с задачей никогда не сталкивались, в любимом инструменте нету средств для ее решения и даже не хватает фантазии, чтобы такую задачу представить - задача есть идиотизм.
пользуясь современной термонологией - слив засчитан. :)


Как Вам сказать ... Вы поставили задачу (на мой взгляд идиотскую) Если бы ВЫ платили мне деньги, то имели бы права требовать от меня решения. Решить задачу ТАК как вы просите на Oracle можно (и у меня вполне хватает фантазии на это). НО есть МАССА более вменяемых способов решить изначальную проблему.

ваши критерии вменяемости опубликуйте, плз.
или код.
а то пока только паразитный траффик организуете :)

Gluk (Kazan)

Наводящий вопрос: накуя мне завязываться на не самую быструю технологию OLE Automation НА СЕРВЕРЕ, когда SQL Loader загрузит ту-же информацию из CSV (вполне себе ексельных) на порядки быстрее. А с использованием External Tables то-же можно будет делать вполне автоматизированно и БЕЗ ЛИШНИХ телодвижений.
Слива не было, я просто НЕ ХОЧУ потворствовать ВАШИМ патологиям

вроде как начинали сравнивать движок СУБД?
в msssql эта фича встроена...
а как в oracle ?
31 янв 07, 13:14    [3718964]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Изопропил
В предложенном "решении" отсутствует контроль входных данных. Это плохо.

есть такое.
С этим довольно успешно боремся путем анализа загруженных таблиц:
анализ метаданых, поиск перепутанных названий полей (столбики в excel поменяли местами) - это динамический sql на поиск совпадющих значениях в полях входной таблицы с полями в итоговой и переформировка входной таблицы на нужную последовательность полей.
Далее отображение кофнликтов оператору, который уже сам или совместно с поставщиком инфы их пытается устранить (сплошной DDL)
наверное с точки зрения oracle жуткая картина, гарантирующая мероприятия по "отрыву",
но в mssql система работает изумительно - заказчик в восторге.
естественно, всё предусмотреть невозможно, и косяки возникют.
но это больше от того, что поставщики информации (особенно новые) не читают правила заполнения файла.
31 янв 07, 13:29    [3719077]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
а то пока только паразитный траффик организуете :)


Не валите с больной головы на здоровую. Паразитный трафик пока что организуете (или инициируете) ВЫ. До вашего появления, беседа протекала в сугубо техническом русле.
Зачем ВАМ это надо - теряюсь в догадках.

Предлагаю вернуться к фичам.

Так что в MS SQL есть такое до чего Oracle "как до Луны" ?
Поверьте, меня весьма живо интересует этот вопрос.

Просьба не возвращаться к openrowset и DDL в транзакциях НЕОДНОКРАТНО обмусоленным в этой теме. Иначе создается впечатление, что больше сказать нечего.
31 янв 07, 13:34    [3719119]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
MGR
andy st

возможность есть через служебные хранимки, кода будет больше. подробнее - BOL.
а в данном случае было сделано допущение, что все файлы будут иметь "Лист1", на котором и будет вестись запись данных.


Не надо меня эртеэфэмить - я не нашёл этого в BOL, а нужно было. У некоторых клиентов стоит русский офис, у некоторых - английский.

ооочень плохо искали. наверное вооще не искали
BOL - sp_addlinkedserver - Example F
промаппить нужного пользователя на логин Admin без пароля
потом
sp_tables_ex 'ExcelSource'
правда с понятием "первый" проблема.
31 янв 07, 13:46    [3719204]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
MGR
Member

Откуда:
Сообщений: 536
andy st

правда с понятием "первый" проблема.


Именно :(
31 янв 07, 13:51    [3719248]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
MGR
andy st

правда с понятием "первый" проблема.

Именно :(

можно попробовать вытащить это дело через OLE и Worksheet.index
31 янв 07, 14:20    [3719476]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

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

правда с понятием "первый" проблема.

Именно :(

можно попробовать вытащить это дело через OLE и Worksheet.index


Ооо, а вот и Automation
31 янв 07, 14:24    [3719513]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
MGR
Member

Откуда:
Сообщений: 536
andy st

можно попробовать вытащить это дело через OLE и Worksheet.index


Сервер БД - не лучшее место для установленного офиса. И для automation.
То есть для полноценной работы с экзелем всё-таки надо использовать клиентскую сторону.
А приведенный Вами пример хорош при разовой работе, когда в существующий скрипт подставляется имя книги, листа, путь, какие-то другие параметры.
31 янв 07, 14:31    [3719578]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

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

Хм. Скажем так, я бы согласился с этим рассуждением, но есть одна тонкость: являясь опытным MSSQL-щиком, Вы должны прилагать специальные дополнительные усилия, чтобы оценить прозрачность его фич - Вы к ним слишком давно привыкли. Ровно так же я не вижу ничего сложного в освоении Oracle на типичном уровне, но никогда не утверждал, что это "проще, освоить MSSQL" - потому что взгляд у меня специфический.

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

pkarklin
Я уже неоднократно в общении с Вами, дабы Вы не трактовали мои высказывания так, как Вам это считается выгодным в данной ситуации, писал: "все, что я говорю, это моя точка зрения". Если Вы потребуете, чтобы в общении с Вами, я добавлял к каждому своему высказыванию IMHO, я буду так делать. Дабы у Вас не возникало желания "повышать" приоритет моей точки зрения до уровня "абсолютного утверждения".

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

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

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

Вы хотите задать этот вопрос человеку, "не знающему SQL"?!

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

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

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

И вот здесь Вы начинаете из этого отсутствия внутренней логики строить целую теорию.

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

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

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

CREATE PROCEDURE AS SELECT
CREATE VIEW AS SELECT

создает существенные неудобства. Я заменяю SELECT другой командой того же класса:

CREATE PROCEDURE AS INSERT
CREATE VIEW AS INSERT

и спрашиваю, почему Вы не протестуете против различия в этом случае; должны ли и в этом случае команда в процедуре и в представлении работать одинаково?

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

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

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

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


Интересный подход. Пока в этом обсуждении всем, кто знает MS SQL такой подход кажеться прозрачным, и, всем, кто знает Oracle с точностью до наоборот.

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

Во-вторых, в силу первого пункта для "прозрачности в MSSQL" неважно, знает ли человек Oracle или нет. Важно, знает ли он MSSQL или нет.

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

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

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

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

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

pkarklin
Только из-за того, что Вам она кажеться не прозрачной? В данном случае Ваше мнение выступает мерилом абсолютной истины? Двойные стандарты, уважаемый Александр?!

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

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


Не надо передергивать!!! Программы, от которых "уши дыбом встают" (кстати, почему уши, у меня обычно волосы) могут создаваться (и самое главное создаются) и на PL\SQL. Это ни есть характеристика инструмента! Это есть характеристика использующего этот инструмент!

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

Вы: вот, надо учить SQL, потом PL/SQL
Я: да, надо учить. Альтернатива - создание плохих программ

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

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

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


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

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

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


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

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

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

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

Интересно, что и кому Вы доказали?! Вы сами себе доказываете, что Вы правы. Ради бога. Для меня Вы пока ничего не доказали.

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

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

В данном случае я рассматриваю sql.ru как "солидный научный журнал". С точки зрения уровня дискуссии имхо это вполне правомерно.

pkarklin
Да и как можно что-то доказать, если нет у собеседников абсолютно разные взгляды на доказуемую область, а именно ее "прозрачность".

Браво! Если перевести на русский, получается так: "Некто pkarklin изначально имеет мнение и никакие аргументы его не переубедят". Да, доказывать что-то человеку с такой позицией непрактично, да я и не собираюсь. Мне достаточно показать зрителям, что это именно Ваша персональная твердолобость.

Как можно доказать - да собственно обычным образом. Определение прозрачности дано, Вы с ним фактически - своими действиями - согласились. Следовательно, есть место для объективной аргументации.

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

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

pkarklin
Но это не так. И это реальная действительность (не только в MS SQL и не только c SELECT).

Между "реальной действительностью" и "редкими исключениями" есть разница, довольно важная.

pkarklin
Хм... Ваш код был скомпилирован и отработал так, как Вы того попросили,

Безусловно.

pkarklin
написав этот код. Ни более ни менее. Вы, писав этот код, исходили из неких своих предположений, как он должен работать.

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

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

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

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

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

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

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

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

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

Не читавший докиЧитавший доки
T-SQLНе сможет работатьСможет работать
PL/SQLНе сможет работатьСможет работать


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

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

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

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

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

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

pkarklin
ибо и то, и то, можно делать и там и там. И с этими же требованиями подходите к реализации к функциям в MS SQL.

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

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

pkarklin
Я готов обсудить с Вами эти вопросы и готов услышать от Вас мнение, что за это Вы поставите "-" MS SQL.

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

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

Побочная линия - "уж если за это ставить минусы ораклу, то начать стоило бы с минусов вот за эти расхождения ms-у". Но это именно как добавочный тезис к основному "нет тут минусов".

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

У меня есть у кого учиться.

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

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


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

На это у меня даже заготовлен стандартный ответ.

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

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

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

pkarklin
Александр, я думаю, Вы прекрасно понимаете, что я хотел сказать.

Павел, когда я прекрасно понимаю, я не задаю вопросов (исключая подчеркнуто саркастические, ироничные итп, по сути являющиеся возражениями). Когда я не понимаю, я задаю вопросы.

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

Разумеется, качество сотрудника может перекрывать недостатки инструмента, но не стоит списывать туда все проблемы и надеяться, что сотрудник вытянет. Тут уместно вспомнить старую фразу "Быстро, качественно, дешево - выберите любые два пункта". Ситуация примерно та же: между качеством работника, качеством инструмента, качеством результата и необходимой трудоемкостью существует вполне четкое соотношение. Хуже инструмент - значит при том же качестве работника либо выше трудоемкость, либо хуже результат.

pkarklin
Я думаю, что и хп в Oracle, можно с имитировать описаные Вами ситуации.

Хм. "Думаю" - это.... объективно :)

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

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

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

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


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

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

Ну а вкратце, почему я ее упомянул: потому что имея такие выборки, легко выдать любой отчет. Скажем: приходы на одном листе, расходы на следующем листе в несколько другом формате. Или допустим на одной временной оси, слева - приходы, справа - расходы (что-то типа full outer join по дате, если так легче представить). Или "приходы и расходы вперемешку отсортированными по дате-времени". Если же возвращать одну выборку, это становится невозможным (точнее, крайне затруднительным - потребуется активная навигация по выборке), потребуется для каждого отчета писать свою питающую ХП. Почему я считаю первый вариант лучшим: потому что в этом случае сервер не зависит от клиента. Задача "добавить или изменить отчет" решается силами программиста отчета, без внесения изменений в серверный код. То есть мы имеем базовый принцип модульности: каждый занимается своим делом (здесь следует отметить, что есть довольно частая практика - "приспосабливать сервер под нужды клиента", которую я полагаю крайне порочной).
31 янв 07, 14:34    [3719607]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
MGR
А приведенный Вами пример хорош при разовой работе, когда в существующий скрипт подставляется имя книги, листа, путь, какие-то другие параметры.


Для этого тоже плох. Слишком много букф для разовой таблички.
Объявление External таблички в Oracle будет раз в пять короче
31 янв 07, 14:35    [3719613]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)
andy st
MGR
andy st

правда с понятием "первый" проблема.

Именно :(

можно попробовать вытащить это дело через OLE и Worksheet.index

Ооо, а вот и Automation

Вас её применение смущает?
31 янв 07, 14:38    [3719639]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)

Просьба не возвращаться к openrowset и DDL в транзакциях НЕОДНОКРАТНО обмусоленным в этой теме. Иначе создается впечатление, что больше сказать нечего.

:) вернемся потом.
Позвольте узнать, тема "гетерогенные репликации" подлежит обсуждению?
31 янв 07, 14:42    [3719669]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
Gluk (Kazan)
Ооо, а вот и Automation

Вас её применение смущает?


В гробу я видел invoke-и на рабочем сервере БД.
Им там не место. Про их производительность я говорил выше.

автор
Позвольте узнать, тема "гетерогенные репликации" подлежит обсуждению?


Почему нет ? Я не ограничиваю НИКОГО в выборе тем (для этого есть модераторы). Я лишь НАМЕКАЮ, что повторное рассусоливание двух малозначительных фич приводит к ощущению, что больше рассусоливать нечего
31 янв 07, 14:45    [3719698]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
MGR
andy st

можно попробовать вытащить это дело через OLE и Worksheet.index

Сервер БД - не лучшее место для установленного офиса.

в mssql 2000 для работы почтовых рассылок нужно было ставить оутлук.
это жизнь...
MGR

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

скрипт работает на разных именах файлов, с одинаковыми названиями рабочего листа уже достаточно долго и им перекачано достаточно много файлов без вмешательста программиста или админа, чтобы не считать это разовой работой.
31 янв 07, 14:50    [3719732]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Добрый день, уважаемые знатоки!

По рабочей необходимости фирме нужно приобрести некое прикладное программное обеспечение (учетная система, предполагаемый объем данных - миллионы записей в таблицах).
На рынки присутствуют только два разработчика: "А" и "Б".

По уровню функционала, сервиса, поддержки оба достойны.
Но "А" - использует в качестве СУБД MSSQL 2000.
"Б" - Oracle9.

Встал вопрос выбора между "А" и "Б".

Я четко понимаю, что многое зависит от криворукости разработчиков.
Но сможет ли MSSQL 2000 потенциально вытянуть такой объем?

Буду признателен за советы.

Спасибо.
Алексей.


зря он здесь такие вопросы задаёт

8)
31 янв 07, 14:55    [3719774]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

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

в mssql 2000 для работы почтовых рассылок нужно было ставить оутлук.
это жизнь...


Это ВАША жизнь
31 янв 07, 14:57    [3719793]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
1024
зря он здесь такие вопросы задаёт


К чему Вы это вообще ? Очередной камень в кусты с целью превратить содержательный (но неудобный) тред в помойку ???
31 янв 07, 14:59    [3719822]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)
andy st
Gluk (Kazan)
Ооо, а вот и Automation

Вас её применение смущает?

В гробу я видел invoke-и на рабочем сервере БД.
Им там не место. Про их производительность я говорил выше.

лично я не использую ole в критичных по времени запросах.
а грузануть прогноз погоды с gismeteo раз в 4 часа и сложить его в табличку - это запросто. ;)
автор
Позвольте узнать, тема "гетерогенные репликации" подлежит обсуждению?

Почему нет ? Я не ограничиваю НИКОГО в выборе тем (для этого есть модераторы). Я лишь НАМЕКАЮ, что повторное рассусоливание двух малозначительных фич приводит к ощущению, что больше рассусоливать нечего[/quot]
дык велкоме.
расскажите, как с этим обстоит дело в oracle
можно ссылками.
31 янв 07, 15:04    [3719894]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 899
Gluk (Kazan)
andy st

в mssql 2000 для работы почтовых рассылок нужно было ставить оутлук.
это жизнь...

Это ВАША жизнь

сорри, забыл уточнить :)
31 янв 07, 15:07    [3719926]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить