Воссоединение SQL в 1995 г. люди, проекты, политика

       

Oracle


Роджер Бемфорд

: Франко, ты не хочешь начать разговор про Oracle?

Франко Путцолу

: Ну, я проходил интервью раньше тебя.

Роджер Бемфорд

: Это так. Хорошо, вы знаете, что я был в Esvel и обжегся на этом, и я вернулся в IBM, чего, возможно, вы и не знаете. Некоторое время я работал в Научном Центре.

К. Мохан

: Это Пало-Альто, не так ли?

Роджер Бемфорд

: Да, Пало-Альто. Там был этот парень, который работал над экспертной системой - я думаю, что его звали Гарри Ринстейн (Harry Rhinstein). Сначала он делал ее на APL, а потом перенес на Pascal, и они на самом деле не знали, как вести производство, так что каждая процедура копировалась много-много раз, и в каждой копии менялось по несколько строк.

Итак, я искал работу и пошел в ресторан в конце Page Mill Road - на Foothill Expressway для встречи с этой охотницей за головами; это была женщина. Я смотрел вокруг в поисках одинокой женщины, ищущей кого-нибудь, и обнаружил женщину, которая стояла и кого-то высматривала, и я заговорил с ней. Был один такой служащий Oracle, и она говорит: "О, Вы знаете Джека Харпера?", который, подобно многим другим продавцам, очень недолго работал в Esvel. Он был в Oracle, и я начал с ней разговаривать. Дон [Слац] имел разговор с Oracle, и он сказал: "Проверьте этих парней". Когда я вернулся в свой офис, я подумал, что, может быть, стоит позвонить в Oracle. Я позвонил в справочную и узнал их номер, и я думал позвонить им - вы знаете, объявиться самому - и тут зазвонил телефон. Я снял трубку, и это была Дженни Оверстрит (Jenny Overstreet), помощница Ларри Эллисона; она звонила мне, чтобы узнать, не хочу ли я придти на интервью. Я полагаю, что это было в 1984 г., так что я сел на свой мотоцикл и покатил в компанию Oracle, которая находилась совсем недалеко, и по дороге попал под дождь. У меня было подробное интервью с Бобом и Ларри. Я нашел, что Ларри обладает большим обаянием и энергией и имеет все возможности добиться успеха. Боб Майнер (Bob Miner) был очень приятным и умным парнем. И я пошел работать в Oracle. Там было странно, поскольку я пришел из IBM и Esvel, где данные заказчика были святыней. В первый день Эд Оутс (Ed Oates), один из первых наших сотрудников, идя по коридору, сказал: "О, трамтарарам, база данных опять накрылась". [смеется] И мы послали им новейшую версию системы. Единственным способом использования Oracle в то время было каждодневное экспортирование всех данных, чтобы можно было заново загрузить базу данных в случае ее поломки. И они были действительно счастливы. Я имею в виду, что заказчикам это не нравилось, но они не слишком переживали, потому что система фактически совсем не использовалась для обработки транзакций; она использовалась как ранняя система поддержки принятия решений. И программное обеспечение было действительно простым. Имелась богатая характеристика: множество этих новомодных встроенных функций. И поддерживалось много типов данных, что было очень полезно. Это там было. Был язык, одобренный IBM, так что Боб и Ларри ожидали, что он станет в будущем стандартным языком. Когда я пришел, они начинали эту стратегию переносимости, в которой действительно было много смысла, потому что в 1984 г. компьютеры были дорогими, и делая программное обеспечение переносимым, можно было существенно расширить сферу использования компьютеров. Что и сделала компания Oracle, и это помогло образовать большой потенциал получения доходов, поскольку они получали деньги, сэкономленные заказчиками за счет перехода к открытым системам. Как они позже поняли, за переход к открытым системам тоже нужно платить.


Том Прайс

: Oracle получал деньги, которые раньше шли поставщикам аппаратуры.

Роджер Бемфорд

: Верно, конкретно их получал Ларри. В течение долгого времени в Oracle ходила шутка Стью Фейджина, одного из прочих основателей Oracle; я полагаю, что он был первым служащим. Всегда, когда мы шли на ланч и тратили кучу денег на ланч или обед, он говорил: "Ну, это всего лишь деньги, и это всего лишь деньги Ларри". Это было ходячей шуткой.

Насчет влияния на Oracle со стороны System R: некоторые идеи пришли из Esvel, некоторые - из System R. Но начальный код, который они написали, в действительности выглядел так, как будто у кого-то была статья с описанием языка, и у них был компилятор и ничего больше. И можно сказать, что он был написан ... Я имею в виду, что все структуры данных были подобны следующему: "Ну, вот этот блок запроса, у блока запроса есть часть выборки, а у этой части ... и у этого есть то-то и то-то". Делалось полностью прямолинейное отображение языка на аппаратуру; очень малое число промежуточных средств. Том [Прайс] работал над этими статьями по поводу всевозможных стратегий соединения, анализируя их. Они никогда их не читали. Было то, что Ларри назвал AI-оптимизатором, который теперь называется оптимизатором, основанным на правилах. Прошло действительно много времени, прежде чем у нас появился оптимизатор, основанный на оценках.

Франко Путцолу

: Это действительно так: когда вы смотрите в код Oracle, в нем не заметно происхождение от System R.

Роджер Бемфорд

: Нет, она была только причиной образования компании.

Майк Блазген

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



Роджер Бемфорд

: Да, в действительности у Oracle SQL-продукт появился раньше, чем в IBM. IBM изобрела язык, но Oracle первой поставила продукт.

Майк Блазген

: Я не знаю, когда стал поставляться первый код Oracle.



Джим Грей

: 1979?

Роджер Бемфорд

: Версия 2. Первой версией Oracle была Version 2, потому что они решили, что никто не будет покупать Версию 1. [смеется] Это правда; еще одна блестящая находка Ларри.

Бред Вейд

: Хорошо, когда Тед Кодд получил звание IBM Fellow?

Майк Блазген

: В 1976 г.

Бред Вейд

: Я помню прием, который они устроили для него в кафетерии строения 28. Тогда он сказал: "В первый раз я напоминаю себе человека, становящегося IBM Fellow за продукт, сделанный другим". Это был продукт Oracle.

Майк Блазген

: Это было очень рано.

Роджер Бенфорд

: Когда я там оказался, они работали над Версией 3, уже почти завершенной парнем по имени Брюс Скотт (Bruce Scott), который потом ушел в Gupta; он написал большой объем кода для вычисления выражений в первой и второй версиях; думаю, что и в Версии 3. Версия 2 была написана на языке ассемблера для PDP-11; Версия 3 была написана на языке С. Он это сделал, и он написал это действительно замечательно, компактный код - очень хорошо структурированный; многое из него осталось и теперь. Я думаю, что следующая версия работала действительно хорошо и была существенно развита. Она стала основой следующих версий. После этого вышла Версия 5 с поддержкой принятия решений и распределенными запросами. И шестая версия была переписана для обработки транзакций.

Франко Путцолу

: Как много было переписано в Версии 6?

Роджер Бемфорд

: Примерно эквивалентно RSS, так что около половины. И все это было отвергнуто и заново написано с нуля.

Джим Грей

: Хотя и с теми же структурами на диске, верно?

Роджер Бемфорд

: Нет, форматы тома изменились. Все было полностью по-другому. В Версиях 3, 4 и 5 строки объединялись в блоки - знаете: байт, байт, байт, байт, байт, байт, байт ... безо всякого индекса и тому подобного. Поэтому, если требовалась строка с порядковым номером двенадцать, то нужно было начинать с начала блока и сканировать столбцы и строки; и в конце концов вы добирались до того, что искали. [смеется] И как бы вы стали обновлять строку или расширять один из столбцов? Ну, вы сдвигаете остаток блока вправо ...



???

: О мой Бог.

Роджер Бемфорд

: Да, поэтому мы изменили это в Версии 6. Я был кем- то вроде ведущего проектировщика Версии 6. Когда говорилось про SARGS ... в то время, то отсутствовало понятие о том, что есть RDS и что есть RSS. Имелся интерфейс, но он все время нарушался. Одна из вещей, которые приходилось делать, - это глубоко погрузиться в середину некоторого блока, оглядеться и пройти через вызовы этих верхних уровней, и в результате выполнялась некоторая конструкция SQL, например, вычислялся подзапрос. И поскольку в Oracle имелось согласованное чтение, то так можно было делать, потому что можно было удерживать этот блок, не запрещая кому-либо другому изменять его: они получали свою копию и изменяли именно ее. Эти вещи мы сохранили, потому что с ними было все в порядке. Но журнализация, восстановление, метод реализации согласованного чтения, блокировки - практически все, что связано с управлением данными, в Версии 6 было заменено. И тогда, только тогда там удалось создать весьма удовлетворительную систему.

Такова, в целом, история Oracle. Есть ли у кого-нибудь вопросы?

Дон Слац

: Ларри начал с копирования System R как есть. Как долго собирался он следовать этому подходу, не вылезая вперед?

Роджер Бемфорд

: Что ты имеешь в виду?

Дон Слац

: Добавление функций. Он начал напрямую с System R.

Роджер Бемфорд

: Да, они взяли опубликованную спецификацию SQL и потом реализовали это, и они добавили вещи, которых хотели заказчики.

К. Мохан

: Даже в Версии 1 у вас были определяемые пользователями функции и т.д.?

Роджер Бемфорд

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

Франко Путцолу

: Когда у них появились формы, средства на основе форм для более простого написания приложений?

Роджер Бемфорд

: О да: я думаю, IAP: Interactive что-то. Это был предшественник SQL*Forms, который появился в третьей или четвертой версии; я думаю, что в третьей. Да, они наняли этого парня - это абсолютно типично для Oracle - они взяли этого парня сразу после школы; умного парня; он немного занимался программированием. И первой вещью, которую он делал, был UFI, а потом он создал IAP, приложение, основанное на формах.



Брюс Линдсей

: Подобное SREDIT?

Роджер Бемфорд

: Там были блоки и были таблицы; это было похоже на редактор таблиц с массой способов перехода из одной таблицы в другую. Отсутствие опыта в Oracle никого не сдерживало. [смеется]

Майк Блазген

: Помню, что я в первый раз увидел работающую систему Oracle на какой-то компьютерной конференции типа SIGMOD или что-то в этом роде. Там была демонстрационная площадка, и на небольшом стенде Ларри Эллисон с еще одним человеком показывали свою систему. Я представился (со мной был Джим Мехл), и Ларри знал о System R и нашей работе и устроил для меня небольшую демонстрацию. Я был впечатлен, потому что система явно была простой, в том смысле, что ... хорошо, через минуту узнаете. Она казалась быстрой. Он загрузил базу данных, выполнил запрос, выполнил операцию обновления, и все это в несколько секунд. База данных была - не знаю точно - может быть, из пяти сотен записей. И она загружалась моментально.

Роджер Бемфорд

: В каком это было году?

Майк Блазген

: Я не помню; вероятно в 1979 или 1980. Больше всего меня впечатлило то, что система работала на маленькой PDP-11. Машина была размером в коробку сигарет. Должно быть, это была версия машины LSI-11, если меня не подводит память по поводу размера. А System R в то время в большинстве мест наших совместных исследований и в IBM работала на 168-х. Теперь мощность 168-й сопоставима с мощностью 486DX2 или типа того, но факт, что это была громадная машина, которая, вероятно, не поместилась бы в эту комнату.

Джим Грей

: Она была с водяным охлаждением.

Майк Блазген

: Это был гигантский компьютер. И Дон [Чемберли] говорил примерно так: "System R не была такой уж большой; всего 1.5 мегабайта кода и 87 тысяч строк кода". Но она на самом деле работал на компьютере размером в эту комнату. А маленькая штучка Oracle работала на машине размеров в ящик сигарет. Я помню это, потому что она стояла прямо там, задвинутая на полку. Она стояла на небольшой полке над столом, подключенная к телетайпу. И это было все, что требовалось, и система быстро работала, и я подумал: "Просто, быстро, дешево; это здорово. Люди будут это покупать". Именно для тех приложений, о которых говорил Роджер: приложения с запросами для поддержки принятия решений.



И все прочее

Межгалактический язык данных: стандарт SQL, Open SQL, ODBC, DRDA

Пат Селинджер

: Джим, ты следующий для разговоров о Sybase, Informix, DEC, Teradata, Ingres, Britton-Lee и Microsoft.

Джим Грей

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

Разные участники

: Нет.

Джим Грей

: Я это сделаю в любом случае! Вот оригинальное руководство по языку SQL (из System R). Всего 40 страниц десятым кеглем шрифта Courier с большим числом номеров ошибок и пустых мест. Язык был действительно простым. Тема реляционных баз данных была горячей, поэтому ANSI основал Relational Database Task Force с целью определения стандарта. Существовала оперативная группа DBTG, у которой была сетевая модель данных CODASYL, и они пытались стандартизовать сетевую модель данных; Дон Чемберлин говорил о том, насколько интересно было изучать сетевую модель данных. Там были эти штуки, которые назывались индикаторами актуальности, и они нравились людям. При выполнении запроса устанавливался индикатор актуальности, и потом можно было прочитать то, на что указывал один из индикаторов актуальности. В терминах SQL, для каждой таблицы имелся курсор. Можно было произнести магическое слово, и курсор для этой таблицы изменялся. Менялся также глобальный курсор. Я правильно говорю?

Дон Чемберлин

: Да.

Джим Грей

: Но нельзя было иметь два курсора на одной таблице. Так что при желании соединить таблицу с ней же самой требовалось запомнить текущее положение, а затем перейти к получению другой записи. Поэтому Database Task Group испытывала большие затруднения; в действительности, никто не хотел это стандартизовать. Так что это стандарт был зомби; он был непоследовательным; я полагаю, что удалось произвести стандартизацию где-то в 1990 г. или что-то в этом роде? Примерно в то же время вышел первый стандарт SQL, это было своего рода недоразумением (quid pro quo), что мы стандартизовали DBTG и реляционный язык в одно и то же время. Но была эта непоследовательная реляционная оперативная группа, и они погружались во все более, и более, и более глубокую воду; много глубокой воды, правда? Они делали свой собственный язык баз данных. Как-то Фил Шоу появился на одном из этих собраний и сказал: "Вы знаете, вы могли бы это сделать", и он раздал им нечто, похожее на это [показывает раннее руководство IBM по языку SQL]. Бумага была опять же напечатана десятым кеглем, но была односторонней, а не двухсторонней. Эти люди, которые находились в безнадежно глубоком омуте, сказали: "Вы правы; мы могли бы это сделать, и это единственный способ добиться прогресса", потому им не удавалось продвинуться каким-либо другим способом. Так что они привязались к этому ... и я думаю, что это был проектный документ этого комитета в IBM, председателем которого был Дон ... ты был Папой SQL или вроде этого? Я что-нибудь исказил?



Дон Чемберлин

: По этому поводу многое сделал Боб Инглс. Я уверен, что большая часть слов в этой книге написана Бобом Инглсом. Боб Инглс изучил System R и написал формальную спецификацию всего, что она делала, полностью и со всеми недостатками. Там содержались все виды странных правил, которые были неортогональными: нельзя было делать GROUP BY, если при этом задавалось UNION; подобные этому вещи. И ни для какой из этих вещей не было особых обоснований, кроме того, что у кого-то не хватило времени сделать их по-хорошему. [смеется] Итак, Боб Инглс изучил System R, и он был очень дотошным и точным, и он точно описал все, что делала система, очень формальным образом. Я думаю, что именно этот документ был там у вас. И тогда люди из комитета по стандартизации вроде как благословили его и сказали: "Это будет наш стандарт".

Джим Грей

: Единственный способ, с помощью которого мы можем добиться прогресса.

Дон Чемберлин

: Они сохранили и все недостатки. Они не пытались как-либо вычистить язык.

Джим Грей

: Верно. Никаких обсуждений того, что означает NULL. Чемберлин вернулся с однодневного совещания в Санта-Тереза и сказал: "Мы провели целый день, решая, как нам следует понимать NULL. Должно ли это означать ABSENT (отсутствующее значение), или NOT KNOWN (неизвестное значение), или NULL (неопределенное значение), или?" Ребята из ANSI SQL не возились, подобно ребятам из Санта-Тереза. Они взяли это, и, по существу, это и есть SQL 1 - стандарт. И это SQL'86, не так ли? ANSI - американцы предложили этот стандарт, но американцы составляют лишь часть международной организации. Международная организация сказала: "Мы заключим с вами соглашение: мы проглотим ваше барахло, если вы проглотите нашу разработку ссылочной целостности" (внешних ключей). Позже должно было появиться приложение, и люди из Международной организации по стандартизации (ISO) были готовы согласиться с этим [SQL 1], если получать возможность написать свой вариант ссылочной целостности. И они написали про ссылочную целостность, что вошло в SQL'89, так что это добавление. Все ли я правильно изложил? Поправьте меня, если я в чем-либо ошибся.



Итак, мы подошли к 1989 г.; у нас было что-то вроде этого [показывает] и приложение, которое было довольно коротким.

К. Мохан

: Ему не терпится перейти к следующей части. [смеется]

Джим Грей

: И на самом деле, здесь находится весь набор [показывает]. И теперь мы принимаемся за SQL 2, вот SQL 2 [показывает], он намного больше. В действительности, я не очень легко ориентируюсь в SQL 2; прошу прощения. Но это масштабный стандарт, OK? И что в нем есть, это определение данных; в нем есть ограничения; в нем есть время; в нем есть ... какие еще хорошие в вещи?

Брюс Линдсей

: Внешнее соединение.

Джим Грей

: Внешние соединения. Большая полнота. Но он очень большой; в нем порядка пяти сотен страниц.

Брюс Линдсей

: И, кроме того, он распространяется на трех языках.

Том Прайс

: Вошло ли что-нибудь, связанное со ссылочной целостностью, в SQL 1?

Джим Грей

: Да, это был SQL 1.1.

Том Прайс

: И это близко к тому, что было реализовано в DB2, или что-то другое?

Джим Грей

: Я думаю, что это разработка Криса Дейта. Вы знаете, у них есть каскадность, и RESTRICT, и ...

Теперь комитет SQL живет своей собственной жизнью и имеет SQL 3. Вот что представляет из себя текущий вариант SQL 3 [показывает трехтомный комплект книг]. И заметьте, что это напечатано девятым кеглем, и очень, очень плотно, и все заполнено разными вещами. Я думаю, честным будет сказать, что большинство из нас не понимают, что же там имеется. Я думаю, что Дон Чемберлин, возможно, потратил много времени ... я уверен, что он понимает страницы этого документа. И теперь они пытаются взять SQL 3 и разбить его на две части: SQL 3 и SQL 4. Вероятно, SQL 3 должен быть одобрен где-то в 1997 г.? И SQL 4 переходит в следующее тысячелетие, что, по моему мнению, правильно характеризует его состояние.

То, что еще произошло,- это ODBC; я перехожу к части Microsoft. Еще произошло то, что когда мы - я, Дон Слац и парень по имени Рао Йендлури (Rao Yendluri) - были в Tandem, то мы сказали: "У нас на самом деле серьезная проблема. Мы получили это ядро баз данных; эту вещь, которая сохраняет байты. Она помнит факты. Но поместить этот в этот компьютер и забрать их оттуда фактически невозможно. У нас нет средств; мы нуждаемся в средствах. Мы не можем создать средства; мы не создаем средства. Мы хотим, чтобы все создавали средства, подходящие для нашей системы. Как мы собираемся привлечь всех к созданию средств, пригодных для нашей системы? Нам нужен стандартный способ, обеспечивающий доступ людей к нашей системе, так же как и к Oracle или Sybase. План A: мы делаем вид, что мы и есть Oracle. Все собираются строить средства, пригодные для Oracle. Но это не слишком удобно, поскольку ставит нас в зависимость от Oracle. Мы должны маскироваться под Oracle, но они могут сделать что-то, чтобы обвалить нас, и т.д. Плюс к этому - их внешние интерфейсы не являются общедоступными. У Sybase есть нечто, называемое Tabular Data Stream, и мы могли бы маскироваться под Sybase и быть системой, которая поглощает Tabular Data Stream и выдает Tabular Data Stream". Так что мы подумали об этом и сказали: "Что действительно нужно миру, так это стандарт клиент/сервер", потому что поставщики инструментальных средств хотят иметь стандарт, на основе которого они могли бы программировать и знать, что их инструменты будут работать со всем чем угодно. Эти ребята хотят быть в состоянии применять свои средства к любому серверу баз данных, а ребята-разработчики серверов хотят, чтобы с их сервером можно было использовать любое средство. Итак, мы сказали: "Нам нужен межгалактический язык данных". Язык Эсперанто, распространяемый по проводам, чтобы каждый мог разговаривать с каждым. Я думаю, что в то же время, в тот же период у ребят в IBM была в точности та же проблема. Они говорили: "У нас есть могучие серверы и нет инструментальных средств; нам нужен межгалактический язык данных". Так что мы с Доном Слацем и Рао Йендлури написали "белую книгу" (white paper) под названием "Open SQL". Мы говорили: "Миру нужен Open SQL, являющийся протоколом общения по проводам: как говорить на SQL по проводам; как получить в ответ таблицы". Мы выложили это, и мы пошли к ребятам в Sybase, и ребятам в Sybase понравилось с нами говорить. Каждый раз после наших разговоров выпускался пресс-релиз о том, как Sybase и Tandem совместно работают над этой проблемой. Не появлялось никакого кода, только пресс-релизы Sybase. И каждый раз, когда мы встречались, они говорили: "Если вы дадите нам сто тысяч долларов, мы дадим вам некоторый код". Но работать с ними было действительно очень странно.



Дон Слац

: И еще они говорили, что это должно быть TDS.

Джим Грей

: Верно. И "Между прочим, что бы это ни было, это наше; мы будем стандартизовать только то, что имеем. Мы будем минимизировать требуемые от нас усилия." Так что в определенный момент мы поняли, что Sybase нас обманывает; мы были слишком медлительны. И тут неожиданно на арене появилось начальство Digital Equipment Corporation. На пороге Tandem появилось множество вице-президентов DEC. Они прошли через такие же размышления и сказали: "Пропади все пропадом, нам нужен Open SQL". Они сказали: "У всех есть эта проблема; мы намерены огласить ее", и они сформировали SQL Access Group. Компания Informix была членом-основателем. Мы отложили участие в основании SQL Access Group, я думаю, месяца на три, пока IBM решала, присоединиться ли ей к SQL Access Group или вступить с ней в конкуренцию (у них был план под названием DRDA). В конце концов они сказали: "Oracle, Informix, Tandem, все эти ребята: они никогда не добьются никакого прогресса". Я вкладываю слова в их уста, но думаю, что они сказали: "Гораздо большего прогресса мы добьемся сами", и они действительно добились довольно значительного прогресса. Они сделали нечто под названием DRDA, конкурирующее с тем, что делала SQL Access Group. А SQL Access Group работала, и работала, и работала и произвела нечто под названием call-level interface - CLI (интерфейс уровня вызовов), пытаясь основываться на некоторых международных стандартах, и сухим остатком этого стало то, что называется ODBC, являющееся видом реализации CLI. ODBC является стандартным способом общения клиентов с серверами. Вы можете послать мне некоторый текст на языке SQL; что он означает, определяется в этих многотомных книгах, которые мы только что видели. И, следовательно, ODBC определяет, как задавать SQL-запросы и получать ответные данные. Пугает то, что множество людей учатся тому, как писать эти вещи. Обучение программировать в этой среде - это серьезное предприятие; я несколько беспокоюсь об этом. Но хорошо то, что учиться программировать в такой манере должны только те люди, которые пишут все инструментальные средства. Так что фактически все поставщики инструментальных средств делают драйверы ODBC, чтобы обеспечить конечным пользователям визуальный интерфейс с рисованием кружочков и стрелочек. Инструментальные средства транслируют GUI в операторы SQL и используют эту библиотеку вызовов для отправки запросов серверу по проводам. Сервер делает свое дело; посылает клиенту результирующие таблицы, а там они отображаются на экране. В ODBC начинают появляться хранимые процедуры и разные другие вещи.



Брюс Линдсей

: Для меня создает путаницу то, что ODBC - это не протокол сервера.

Джим Грей

: Верно, это API.

Дон Слац

: Сюда не втягивается DRDA.

Брюс Линдсей

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

Джим Грей

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

Том Прайс

: Имеются драйверы ODBC для вещей, отличных от Microsoft.

Джим Грей

: Верно. Двойственность того, что происходит, состоит в том, что одно из средств ODBC позволяет спросить парня на другом конце: "Кто ты есть?". Хорошими ответами являются "Я Oracle", или "Я Sybase", или "Я Microsoft SQL Server". Поставщики инструментальных средств договариваются, и если это Microsoft SQL Server, то они ведут себя специальным образом, и имеется транспорт, ведущий к Microsoft SQL Server. Имеется другой транспорт, который ведет к Oracle; имеется другой транспорт, ведущий к Sybase. И Microsoft SQL Server и Sybase очень близки. Так что мы начинаем иметь интергалактический язык данных. Это не решило проблему Tandem; Tandem должен теперь маскироваться под одну из этих трех личностей. По крайней мере, это решило проблемы поставщиков инструментальных средств, поскольку у них имеется стандартный программный интерфейс. Вы правы, и, может быть, нам действительно стоит теперь рассказать историю DRDA?

Пат Селенжер

: Вперед.

Том Прайс

: А IBM пока не поддерживает ODBC?

Джим Грей

: Ну, они делают это в мире UNIX. Мир RS/6000 поддерживает ODBC. Я не знаю, имеется ли драйвер ODBC в мире MVS. Я думаю, что он существует в мире AS/400.

Пат Селинджер

: Точно существует.



Дон Слац

: IBM никогда не присоединялась к SQL Access Group, но ??? пришло, и они послали туда Фрэнка Пеллоу из IBM Toronto, так что он всегда там был.

Том Прайс

: А если вы имеете Sybase или Oracle, они обеспечивают драйверы, или вы должны брать их у сторонних поставщиков?

Джим Грей

: Когда впервые начались поставки ODBC от Microsoft, они включили драйверы для Oracle и Microsoft SQL Server, а тем самым и для Sybase, и несколько других, и они начали получать множество нареканий от заказчиков по поводу версий и т.д. Так что, я думаю, что сейчас вы действительно получать драйвер от провайдера; Microsoft не поставляет их, но вы можете их скачать.

Пат Селинджер

: IBM обеспечивает версии для самой себя, и есть такие компании как Q+R, у которых они имеются.

Шел Финкельштейн

: Стандарт SQL определяет, как ... в определяющей части стандарта теперь имеются эти вещи, называемые частями, одна из которых - Call-Level Interface - ужасно близка к ODBC. Так что теперь ODBC - это не просто вещь от Microsoft; ODBC - это часть стандарта.

Джим Грей

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

Шел Финкельштейн

: И также имеются долговременно хранимые модули. Есть эта новая часть с предложениями для темпоральных баз данных, плюс к этому, выполняется работа над отдельным стандартом для мультимедиа. Так что, то, что говорил Джим, - это всего лишь малая часть всех замечательных создаваемых вещей. Я прибыл в Оклахома-Сити (Oklahoma City) через неделю после участия в собрании комитета по стандартизации SQL ???

Джим Грей

: У нас происходит Воссоединение SQL, и я думаю, что, вероятно, одной из важных вещей, на которые стоит обратить внимание, является то, как SQL превратился в межгалактический язык данных. Как клиенты общаются с серверами, если им нужно посылать структурированные данные. Есть другой межгалактический язык данных - IDL, который предназначен для удаленного вызова процедур, и третий - HTTP, используемый, фактически, для Web и Mosaic, и, похоже, что в конце концов победит HTTP.



Итак, DRDA - это подход, выбранный IBM, вместо того, которому следует SQL Access Group. Он в гораздо большей степени посвящен тому, что из себя представляет протокол передачи данных по проводам. Формату сообщений, передаваемых по проводам. Что ты говоришь [жесты?] и протокол: я говорю это, ты говоришь это. Мы ввели аббревиатуру для этих форматов-и-протоколов - FAP (formats-and-protocols). В действительности, ODBC не имеет FAP; это вызовы процедур, а что происходит ниже - это таинство, магика. Фактически, внизу находится драйвер от одного или другого поставщика. Это ужасная ситуация, если только не имеется только один вид клиентов и только одна версия каждого сервера, потому что вы должны взять конкретную вещь; в противном случае вы столкнетесь с проблемой N квадратxv. Одним из удививших меня и, я думаю, многих других людей фактов было то, что ряд разновидностей клиентов исчез, главным образом по причине успеха Windows. Во всяком случае, DRDA является стандартом IBM, она поддерживается в DB2 и поддерживается в продуктах IBM, и ...

xv Имеется в виду, что для обеспечения связи n разных клиентов с m версиями разных серверов потребуется nxm драйверов ODBC. (Прим. переводчика.)

Пат Селинджер

: И двадцать других поставщиков.

Джим Грей

: И двадцать других поставщиков, это верно.

Роджер Миллер

: И X/Open.

Брюс Линдсей

: DRDA пригодна для поддержки внутренности ODBC. Ее можно использовать для формирования стека ODBC.

Джим Грей

: Можно. Интересно; мне кажется, что всем двадцати поставщикам платят за поддержку DRDA. Я говорил с людьми в Informix и они сказали: "Да, мы это поддерживаем, потому что IBM платит за это".

Пат Селинджер

: Я не верю, что это так. Насколько я знаю, это не так.

К. Мохан

: Нет.

Роджер Миллер

: Я в достаточной степени уверен, что мы не платим.

Джим Грей

: OK.

Роджер Миллер

: Мы все упростили, насколько это было возможно. Мы проводили обучение в привлекательных местах и обеспечивали консультации. Мы действительно серьезно работали, чтобы дать поставщикам возможность использовать DRDA.



Джим Грей

: Но они должны писать код.

Роджер Миллер

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

Джим Грей

: Так что вы думаете, что этот подход добьется успеха? Это и будет межгалактический язык данных? Вы думаете, что это и будет FAP?

Пат Селинджер

: Кто знает? Он определенно набирает некоторую популярность среди людей, которых заботит эффективность.

Брюс Линдсей

: Интересный факт относительно ODBC; похоже, что там игнорируются вопросы эффективности. Это строго динамический интерфейс; нет способа выполнить через ODBC статический SQL.

Джим Грей

: На самом деле, там есть хранимые процедуры, так что ...

Брюс Линдсей

: Ну, хранимые процедуры и связанные процедуры - это не совсем одно и то же, но они досточно близки.

Джим Грей

: Они лучше. [смеется]

Teradata; семейство Ingres: Relational Technology, Britton-Lee, Sybase, Microsoft

Джим Грей

: Итак, посмотрим. Teradata. Вот некоторая подоплека. В UCLA был парень по имени Фил Нехес, и он сказал: "Мы должны обеспечить параллелизм на распространенной компьютерной аппаратуре". Он вместе с еще несколькими людьми основал эту компанию, и, я полагаю, в 1994 г. они произвели первое параллельное ядро SQL. Это очень похоже на историю Tandem: что-то типа пони, которая может только скакать. У них не было ссылочной целостности; у них не было всех этих причуд. Вы давали системе SQL-запрос; она возвращала ответ, очень быстро и, по-видимому, дешево, поскольку она работала на процессорах Intel и общедоступных дисках. Компанию Teradata купила компания NCR; NCR была куплена AT&T; а последнее, что я слышал про AT&T ...

Среди других направлений была эта полностью другая разработка, которая велась в U.C. Berkeley в рамках проекта INGRES. В проекте INGRES имелся язык QUEL. Они образовали компанию, которая реализовала QUEL. QUEL дрался с SQL зубами и когтями, существовало множество доводов в пользу того, что QUEL лучше SQL, и в нем действительно была лучше сделана работа с агрегатами. Имеется много областей, в которых QUEL лучше. Некоторые люди в Ingres теперь чувствуют, что причиной их меньшего успеха было то, что они боролись с SQL вместо того, чтобы включить его в QUEL; тем самым они предоставили Oracle возможность отличиться. Факт, что ...



Майк Блазген

: Кстати, у меня был телефонный разговор со Стоунбрейкером, когда я жил в Вашингтоне, и я уехал из Вашингтона в июне 1983 г. Так что, это очевидно было раньше. Я сказал: "Я думаю, что дела у Oracle идут хорошо". Он сказал: "Почему это?" Я сказал: "Потому что они среди тех немногих, кто поддерживает SQL помимо IBM". Он сказал: "Это состояние сохранится не дольше нескольких недель. Все заняты этим; это сделано". Я бы сказал, что к концу 1982 или к началу 1983 г. они были далеки от этого; они приняли это решение. Я не знаю, когда они начали поставку своего первого кода.

Том Прайс

: Хотя в первом коде, который они начали поставлять, SQL был реализован на основе QUEL ...

Майк Блазген

: Это был see-QUEL. [смеется] Это верно.

Том Прайс

: Что заставило меня нервничать по поводу покупки системы.

Джим Грей

: Была еще эта нитка. Из проекта INGRES вышла группа Britton-Lee. В эту группу входили Паула Хоторн, Боб Эпштейн, Майк Убелл и, вероятно, много других людей. И они создавали машину баз данных. В ту эпоху было широко распространено мнение, что можно действительно добиться гораздо лучших результатов, создав часть аппаратуры специального назначения, операционную систему специального назначения, а затем систему баз данных. Построить ее из чистого металла, и все будет работать гораздо быстрее. Я думаю, что Роджер упоминал, что это было и частью концепции Eagle. И Луиз Мадрид ...

Роджер Бемфорд: Я думаю, что мы действительно верили, что от этого можно получить доход; я думаю, что мы действительно верили, что это удешевит создание системы; что будет проще продавать.

Джим Грей

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

Дон Слац

: Множество специальной аппаратуры.

Джим Грей

: У них был акселератор, который был их основной хитростью ... В свою очередь, ребята из Britton-Lee образовали Sybase, и появилась Sybase. Насколько я понимаю, ключевой особенностью Sybase было то, что они работали на UNIX; они не использовали никакие службы UNIX, кроме единственного процесса. Они работали напрямую с дисками; они образовывали единственный процесс и использовали его в многопотоковом режиме, и в этой среде обрабатывали SQL, а в действительности - DB-Library. Они не были большими энтузиастами или последователями SQL. У них была традиция QUEL; они происходили из INGRES. Поэтому ключевым фактором, который позволил им добиться успеха, было то, что у них была отличная производительность. Посылаемый запрос обрабатывался внутри этого процесса; никакой диспетчеризации операционной системы, никакого ввода/вывода операционной системы, только прямые обмены с диском. Так что их производительность в три раза превышала показатели любого другого. Они стремились позиционироваться как основанное на архитектуре клиент/сервер открытое средство управления базами данных.



Том Прайс

: Они работали с Microsoft.

Джим Грей

: И компания Microsoft взяла их код и продавала его для платформы OS/2. Поводом для этого было то, что около 1986 г. IBM пыталась захватить рынок PC, и у них была собственная операционная система - OS/2 - у них была собственная аппаратура. В Microsoft говорили, что они должны каким-то образом защититься от того, что называлось OS/2 Extended Edition. Существовала базовая OS/2, на основе которой должна была появиться едва ли более дорогая Extended Edition; планировалось иметь на этой платформе систему баз данных, и компиляторы, и средства запросов - встроенный QBE, и все такое прочее. Поэтому в Microsoft почувствовали, что им нужно иметь нечто подобное. Они отправились в Sybase и сказали: "Мы возьмем ваше ядро SQL, сделанное ребятами из Sybase, и это будет наша Microsoft Extended Edition". И Microsoft вывел Sybase в мир OS/2. Отношения между Microsoft и Sybase не были теплыми и сердечными. Когда пришло время портировать Sybase на NT, Sybase позволила Microsoft выполнить эту работу. И затем в некоторый момент произошел развод, похожий на развод с IBM по поводу OS/2: IBM будет делать OS/2, а Microsoft пойдет своим путем. Произошел аналогичный развод: Microsoft стал владеть кодом Sybase, и теперь Microsoft SQL Server двигается собственным путем, и они делают его более соответствующим SQL, добавляют GUI и т.д. Теперь это основная сила в мире баз данных. И я думаю, что любого в этом мире сводит с ума то, что этот продукт очень дешев. Порядка пяти тысяч долларов за сервер по сравнению с сотней тысяч долларов. Этот сервер в состоянии выполнять сотни транзакций в секунду. Жуть. Пат, я ...?


Содержание раздела