Активные базы данных

В стандарте SQL:1999 отдается должное активным базам данных, хотя и на несколько лет позже появления их реализаций. Эта возможность обеспечивается через средство, называемое триггерами (triggers). Как известно многим читателям, триггер - это предоставляемое разработчикам базы данных средство заставить систему баз данных выполнять некоторые операции каждый раз, когда приложение запрашивает выполнение определенных операций над указанными таблицами.

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

CREATE TRIGGER log_salupdate BEFORE UPDATE OF salary ON employees REFERENCING OLD ROW as oldrow NEW ROW as newrow FOR EACH ROW INSERT INTO log_table VALUES (CURRENT_USER, oldrow.salary, newrow.salary)

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

Анотация

Воссоединение людей, которые работали над System R и ее производными, включающими SQL/DS, DB2 и R*, состоялось в Асиломаре 29-го мая 1995 г. Этот материал представляет собой отредактированную стенограмму дискуссий с включением изменений, представленных участниками. Предлагается неформальный, но полученный из первых рук отчет о рождении SQL, истории System R и происхождении ряда других реляционных систем внутри и вовне IBM.

Я собираюсь нанести небольшой удар

Джон Науман

: Я собираюсь нанести небольшой удар по Eagle. Когда я познакомился с Джимом, мы только что перебрались [в Пало-Альто] и работали над проектом, у которого тогда не было названия. Я не думаю, что он назывался Eagle, когда ты оказался там.

Джим Грей

: Нет, он назывался VSS.

Джон Науман

: Но один парень из маркетинга посмотрел на слайд - не на слайд, на постер; в IBM было много постеров - и этот был посвящен лаборатории Санта-Тереза с этим парящим орлом. И он посмотрел и сказал: "Вот так мы и назовем проект; мы назовем его Eagle". Мы называли его несколько по-другому - VSS, и нам пришлось снова пройти по всему документу (к этому времени спецификация занимала, вероятно, сорок, или пятьдесят, или восемьдесят страниц) и все заменить ... я не думаю, что в редакторе, который мы тогда использовали, имелась опция глобальной замены, поэтому при применяли SCRIPT, так что в &PROJVAR содержалось название проекта, и достаточно было поменять содержимое &PROJVAR, чтобы получить везде Eagle. Когда прошло около шести месяцев после нашего перемещения в Санта-Тереза, нам стало понятно, что там нет никаких орлов, и мы решили снова изменить название, и на этот раз мы изменили его на Ampersand, поскольку, казалось, что лучше использовать такое название, чем пытаться все время менять название проекта; мы не нашли ни одного человека, который понял бы, что это означает.

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

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

Джон Науман: Это неправда. Мы просто устали пытаться придумывать имена, а этот парень из маркетинга уволился, поэтому мы решили назвать проект Ampersand. Вероятно, в том, что проект близится к смерти, меня убедило то, мы работали над ним в Санта-Тереза около года, и имели регулярные собрания для обсуждения документа. Мы делали этот документ еще когда были в Пало-Альто, значит мы работали над ним уже больше года. Среднее собрание выглядило следующим образом: вы приходили в комнату для обсуждения документа - спецификации, и люди начинали говорить о том, какие там были вдовы и сироты. Все ли знают, что такое вдовы и сироты? Это была тема разговора: "На этой странице имеется вдова; поправил бы ты это". И тогда я сказал: "Нет, так делать неправильно. Вероятно, нам не следует делать это. Этот проект обречен". И он был обречен. Мы старались понять, как двигаться вперед, и что делать со средствами баз данных. Насколько я помню, мы решили, что нам следует перейти к использованию реляционного подхода, но не были уверены в том, как это сделать. И я помню много собраний с участием Фрэнка Кинга.



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

: Когда это было?

Джон Науман

: В 1978-1979 гг. К тому времени Франко работал над заменой RSS - менеджером данных - и мы бились над тем, что делать с верхним уровнем - частью системы, обеспечивающей реляционное хранилище данных. Имелись два лагеря. В один лагерь входили мы с Доном Хадерли (Don Haderly), а другой составляли Фрэнк Кинг и все из исследовательского отделения. Мы считали, что поскольку MVS была не тем же самым, что VM, то было трудно эффективно использовать имеющиеся средства в среде MVS, и нам нужно было основательно реструктуризовать их. Ребята из System R полагали, что такая масштабная оптимизация не требуется; и без этого все будет OK.

Джим Грей

: Люби мою собаку.



Джон Науман

: Любишь меня; полюби мою собаку. Я отчетливо помню тот день - на самом деле, я в то время работал для Боба [Джойллса] - Боб пришел и сказал: "Нет, ответ таков, что ты должен взять эти вещи из System R". И я сказал: "OK. Если это то, что ты хочешь делать, то это деловое решение. Давай делать это". Итак, мы начали над этим работать. Мы потратили много времени и собрали группу - некоторые люди присутствуют в этой комнате, включавшую Джея Йотерса, отсутствующего здесь сегодня, Жозефин, Роджера, которого я переманил с другой работы - я думаю, что IBM была его четвертым местом работы, и когда я нанимал его, он говорил мне, что не собирается долго здесь оставаться, но он хотел получить некоторый опыт работы в большой компании, [смеется] а тогда, я думаю, она была больше, чем сейчас.

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

: Обычно я непредсказуем.

Джон Науман

: Давайте посмотрим; мы наняли Морта - Джона Мортенсона (John Mortenson) - Джон уже работал в компании, мы взяли его в группу. Мы наняли Джерри Бейкера (Jerry Baker), который, вероятно, сделал больше всех денег - следующий за Ларри Эллисоном; он работает на Ларри; он твой босс?

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

: Нет, он не мой босс.

Джон Науман

: Он в одной из организаций разработчиков.

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

: Портирование.

Джон Науман

: OK, это то, что он делал, когда ушел; он перешел в Oracle, чтобы выполнять портирование на платформах UNIX, поскольку у него была подготовка в области ОС UNIX из Техасского университета и ему не так уж нравилась MVS. И он заработал кучу денег; я думаю, что остальные работали большей частью на пользу человечества.



Джим Грей

: Спасибо; мы ценим это.

Джон Науман

: Но на самом деле, мы получали массу удовольствия. Происходило множество интересных вещей. В некоторой степени нам помогал Джим. Много помогал Франко. Франко бился над тем, как реализовать DL/1 и SQL с использованием одних и тех же базовых структур, и позже он снова пытался это сделать, как я упоминал раньше. Но была масса удовольствия. Причина, по которой я ушел - я покинул IBM в середине 1981 г. - только что ушел Джим, и он позвонил мне и сказал: "Слушай, почему бы тебе не поговорить с Tandem; они ищут человека для управления одной из своих групп". И я пошел и поговорил с ними. Джим написал трактат под названием "MIPS Envy" - уверен, что некоторые из вас помнят его - появление которого было аргументом к тому, что он ушел; я думаю, что в этом есть доля истины. Когда мы работали над DB2, у нас был терминальный зал в конце коридора с шестью терминалами 3270. Это все, что мы имели, весь компьютерный ресурс, который был доступен для работы над DB2. Постепенно мы получали больше и больше терминалов 3270 и ставили их в офисы, что было чем-то вроде революции. Ни у кого не было терминалов в офисах; были терминальные залы, в чем имелся смысл.

Джим Грей

: И вам разрешалось подключаться к системе только в определенное время, не так ли?

Джон Науман

: Терминалы были дорогими. Да, можно было работать в уикенды, а также до восьми и после шести. Поэтому я, Хадерли, Бейкер и еще несколько других людей приходили в четыре часа утра, иногда включали радио в четыре часа утра и слушали эти китовьи звуки. И мы удивлялись тому, что происходило; почему мы здесь? чего мы реально хотим добиться? Меня расстраивали те же самые вещи, что и Джима, но я ощущал себя бесполезным, потому что к 1981 г. я работал над проектом около четырех лет - если учитывать время работы над Eagle и не считать время работы над FS - и я мог видеть, что система была почти сделана. Это было в середине 1981 г., за шесть месяцев до начала поставки, и я понял, для меня настало время уйти, поскольку к этому все сходилось. Так что я сказал Дону: "Я ухожу отсюда. Ты можешь принять все на себя; все происходит нормально". В третий раз я поступил так по отношению к Дону - ушел из проекта, над которым мы работали. Но для завершения этого проекта понадобилось немного больше времени.



Итак, я ушел в Tandem, а потом мы завербовали в Tandem Франко, завербовали Майка [Понга] (Mike [Pong]), завербовали ряд других людей. Мы украли Дона у Эсвела (Esvel).

Дон Слац

: Не украли. Я ушел.

Джон Науман

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

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

: Да, я испытывал такие же ощущения.

Джон Науман

: И я думаю, что в этом была одна причин того, что пришел Франко и другие люди. И в Tandem мы добивались результатов гораздо быстрее, и я думаю, что по этой причине нам было гораздо веселей. Я проработал в Tandem четыре года и в 1985 г. после перехода в 3Com я прочитал о полном выпуске DB2. Потребовалось еще четыре года, чтобы получить полный продукт. И насколько я знаю из рассказов Дона, Жозефин и других людей, много усилий потребовалось для того, чтобы заставить работать систему в среде MVS, которая ни в коей мере не являлась простой системой, и я думаю, что мы все недооценивали сложность того, что собирались сделать с удовлетворением имевшихся требований к производительности.

Роджер Миллер: Как только мы начали поставлять систему первым заказчикам в 1982 г., они стали использовать в своих дискуссиях массу ругательств. Первые голоса звучали весело: "О мой Бог, это увлекательно". Но сразу появились все эти вещи, которые мы делали, а Джон говорил, что мы никогда не должны были этого желать. Вещи, подобные Cold Star: "О, нет; базам данных никогда не понадобится Cold Star". Для ввода в действие Cold Star нам фактически понадобилось десять или пятнадцать человеко-лет. Понадобилось неприятное, трудное программирование. Мы почесали в затылках и сказали: "Почему заказчик может захотеть иметь эти средства?" И ответ был следующим: "Вопрос не в том, почему это им не нужно, а в том, почему у тебя этого нет". Так что мы двигались от проблемы к проблеме и продолжали находить ошибки. О, Джерри Бейкер был вынужден шевелить мозгами, потому что Джерри был любителем языков высокого уровня, и он работал в RDS, но у него были эти фрагменты, у него был этот склеенный код, и Джерри даже не хотел знать, что там делается, просто склеивал вместе фрагменты; мы не могли наладить много фрагментов и были вынуждены латать и клеить. Итак, в ноябре 1982 г. мы поставили систему шестерым заказчикам; к марту 1983 г. - восемнадцати. Большое событие - Blow-up Announce - и, как мы объявили, мы производили поставки сорока - пятидесяти - шестидесяти заказчикам: 7-го июня 1983 г. Дела неожиданно пошли на подъем, мы производили первые поставки и двигались от проблемы к проблеме. Шестнадцать мегабайт памяти - это немного; на каждой PC стоит по крайней мере столько, правильно? Но у вас только восемь из шестнадцати, восемь мегов, когда вы начинаете пропускать много пользователей ниже нормы. Система не работала, и здесь появилась XA и MVS XA с 31-битовой адресацией, и целый стек новых проблем, и несовместимости; поэтому нам не было слишком комфортно работать в MVS. Какие из этих сервисов выходят за пределы нормы? "Мы не скажем" - вид ответа; не было списка таких изменений.



Том Прайс

: Получите дамп.

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

: Да, да, только попробуй; тебе это понравится. И так мы крутились и вертелись, и это было мучительно. Каждый раз приходилось подниматься и говорить с людьми из исследовательского отделения, и они говорили: "Вот так так, я не понимаю; это работало, когда я ушел". Действительно доставляло удовольствие, когда иногда приходил Мохан и говорил: "О, вы знаете, это на самом деле трудно". Это правда не было просто. Поскольку тогда мы начали наращивать число пользователей, в сентябре 1984 г. мы занялись проблемами контролируемой доступности; общей доступности, а потом, в апреле 1985 г. выполнили окончательную очистку кода - к этому времени мы закодировали второй выпуск. Второй выпуск вышел примерно через год после этого. Во втором выпуске мы выбросили фрагменты и построили Structure Gen подобно тому, как вы, ребята, делали HOP, и начали говорить "Ах ты, Боже мой". По-существу, второй выпуск делался следующим образом: поговорить с этими первыми 250 пользователями, получить их пожелания, встроить соответствующие возможности в продукт, сделать его успешным. Мы должны были что-то делать, потому что они приставали и приставали, но после этого становилось немного менее интересно.

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

: Можешь ли ты что-нибудь сказать о дуальной стратегии баз данных?

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

: Ты имеешь в виду дуэльную стратегию баз данных?

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

: Велась ли внутри IBM большая полемика по поводу дуальной стратегии?

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

: У нас всегда были отношения любви и ненависти с ребятами из соседней башни, поскольку IMS почти всегда была в соседней башне. С одной стороны, это ужасное наследство; с другой стороны, часто в дверь входят заказчики и говорят: "Я должен сделать выбор между IMS и DB2; как мне это сделать?" И имелся значительный антагонизм - если хотите, как между конкурирующими проектами - по поводу ресурсов.

К. Мохан

: Кто-нибудь должен что-нибудь сказать об этом заявлении, которое Фрэнк Кинг собирался сделать в Австралии, и которое стоило большой головной боли. Это был конгресс IFIPS или что-то в этом роде, правильно? Когда он рассказывал о состоянии реляционных баз данных и собирался сказать, что это ...



Роджер Миллер: О да, и что это, по существу, убьет IMS. И вся наша команда ожидала неприятностей ...

К. Мохан

: Это было в 1981 г.? Я забыл год. Это был какой-то конгресс IFIPS, где он ...

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

: Должно быть, это был 1980 г., потому что конгрессы IFIPS проводились раз в два года.

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

: И последствия для нас были минимальными. Мы не были объявлены. SQL/DS была близка к выходу, но SQL/DS была недостаточно развита для обработки транзакций. SQL/DS - это VM, возможность выполнения запросов и не очень большие базы данных. Сегодняшние большие базы данных содержат терабайты, и реальные живые заказчики во многих ситуациях создают базы данных размером шесть-восемь-десять терабайт. У SQL/DS кончается горючее за пределами диапазона с границей в десять сотен мегабайт - один-два гигабайт - это база данных не категории high-end. Мы всегда хотели масштабировать ее - о, до шестидесяти четырех гигабайт, потому что по глупости считали, что шестидесяти четырех гигабайт [на таблицу] будет достаточно в течение долгого времени.

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

: Тогда я думал, что это все равно, что бесконечность.

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

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

???

: Когда вышла DB2 для MVS, она тоже не объявлялась как транзакционная система, правильно? Это была система поддержки принятия решений.

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

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



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

: И когда же ситуация изменилась? Когда DB2 начали воспринимать как нечто подходящее для OLTP?

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

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

Майк Блазген

: На пять лет раньше я, бывало, рассказывал об этом.

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

: Забавно, что я только что просматривал свои материалы про DB2 и руководство Version 1 General Information. Я просматривал папки и говорил: "Это выглядит как достаточно точный перевод; нет только Дона и его бороды". Но многое в этом материале не менялось в течение двух десятилетий.

Брюс Линдсей

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

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

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

Брюс Линдсей

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



Жозефин Ченг

: Брюс, это, может быть, было так в прошлом, но я думаю, что ситуация меняется. Если посмотреть на инвестиции, сделанные IBM в новые продукты, такие как DB2 Client/Server, то видно, что они весьма существенны.

Брюс Линдсей

: Ситуация изменилась.

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

: Здесь мы находимся вдалеке.

Майк Блазген

: Фрэнк Кинг, например, жестко настаивал на том, чтобы System R принималась такой, как она есть. Это не обсуждалось. Потом он ушел. Так что он перестал быть движущей силой проекта. Но он продолжал играть определенную политическую роль, вроде выступления в 1980 г., о котором говорилось раньше и которое, я думаю, состоялось после его ухода. Один из вопросов, на которым я работал, хотя находился в Вашингтоне и имел работу, никак не связанную с базами данных, заключался в том, что все считали, что нам нужно было бы всегда поддерживать DL/1; мы должны были бы поддерживать старые программы. Если вы загляните в отчет Pratt & Whitney, то увидите, что там говорится: "Задача номер один состоит в том, что мы должны иметь полную поддержку данных и программ IMS". Когда этого не стало? Только потому, что никто не делал этого?

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

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

Майк Блазген

: Даже Фрэнк Кинг, когда он работал на Боба Эванса, считал, что мы должны сделать это.

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

: О да. Это оговаривалось.

Майк Блазген

: И все же мы отбивались тем, что не можем этого сделать. Если бы могли, то сделали бы.

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

: Точно. У нас были спецификации, у нас был работающий код, мы поддерживали работоспособность, и мы сказали: "Можем ли мы поставлять продукт в таком состоянии?" Мы сказали от имени IBM: "Вот продукт; мы можем его поставлять, но примут ли его заказчики?" Мы опробовали его на нескольких заказчиках, и самым ласковым, что они сказали, было "Нет, черта с два". Хорошо было иметь честных заказчиков.



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

: Это было связано с эффективностью, блокировкой на уровне страниц, с функциональностью?

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

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

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

: Когда это умерло?

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

: По существу, во втором выпуске. Потому что у нас был второй выпуск DB2, который имел 1986 г. статус GA (General Availability). В 1984 или 1985 г. мы решили ориентироваться на то, что не можем делать DL/1 и будем двигаться по своим рельсам. Будем поддерживать реляционные возможности и делать то, что должно быть в реляционных СУБД для удовлетворения потребностей заказчиков.

Дон Слац

: Я не уверен в точности даты, может быть, Дон [Чемберлин] сможет помочь, но Фрэнк Кинг распорядился, чтобы мы с Бобом Тейлором (Bob Taylor) отключились от проекта на пару месяцев и рассмотрели возможность поддержки вызовов DL/1 - я думаю, что это было в 1978 или 1979 г.; ты помнишь? Я работал на тебя; ты знал?

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

: В группе, которая, по существу, сделала это для нас, был Сид Корнелис (Sid Kornelis), который пришел из IMS. Сид знал IMS вдоль и поперек.

Джим Грей

: Имелось пятьдесят тысяч тестовых вариантов ...

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

: Да, у нас имелось большое количество тестов IMS.

Джим Грей

: ... пятьдесят тысяч, число, пугающее воображение.

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

: У нас был Ллойд Харпер (Lloyd Harper), имевший длинную историю многих и многих продуктов, которые никогда не поставлялись. У нас был Боб Инглс, частично работавший на Хомера [Леонарда] (Homer Leonard), и Хонер был в одной шеренге с Бобом Эвансом, говоря: "Этот продукт останется игрушкой до тех пор, пока в нем не появится поддержка DL/1". Они собирались начать поставки не раньше того, как мы осознаем, что не имеет значения, устраивает нас это или нет; мы не смогли бы продавать систему, если бы согласились.



Майк Блазген

: И никто из этих хороших ребят не выиграл, правда? [смеется]

Джим Грей

: Я думаю, Oracle. [смеется]

???

: Нет, он имел в виду Tandem. [смеется]

Майк Блазген

: О, SQL, ведь наша встреча посвящена SQL. SQL выиграл.

Жозефин Ченг

: Я везучая. Сразу после окончания школы я поступила в IBM и работала в проекте Eagle. В то время были стены и двери, в которые никого не впускали. Вы знаете, что у нас в Санта-Тереза все башни соединены. Они специально поставили двери, чтобы ограничить все связи с другими зданиями - для прохода требовался специальный значок. Итак, я вошла в состав участников проекта, и Франко усердно работал; прикомандированный к STL Ирв также работал очень усердно. Временами я видела Джима [Грея] и также временами слышала громкие крики, и я знала, что это Энди [Хеллер].

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

Майк Блазген

: Было бы очень мило с твоей стороны.

Жозефин Ченг

: Да. Может быть, в следующий раз меня не пригласят. [смеется] На моем столе всегда лежало много статей про System R, помогающих мне понимать код. Например, имелся раздел, в котором говорилось про узлы PTREE. Узел дерева грамматического разбора содержал поля с именами P1, P2, P3, P4, P5. И чтобы понять смысл, требовалось заглянуть в справочник: содержимое поля P1 имело разный смысл для разных типов узлов. Если это узел, соответствующий столбцу, то P1 должно означать "указатель на узел таблицы", а P2 означает "указатель на дескриптор". К концу работы все стены моего офиса были завешены клочками бумаги.

Один из модулей - я не знаю, кто это писал - содержал семантическую подпрограмму, которая проверяла совместимость типов. Это писал Франко? Был реализован интересный алгоритм проверки совместимости типов. Брался остаток от деления на четыре и сравнивался с родовым типом для проверки того, не совпадают ли они. Ты удивлялся: "Почему на четыре?" Оказывается, потому что это дает возможность использовать четыре разряда. Должно быть, проектировщик думал, что четырех разрядов достаточно, чтобы охватить любой поддающийся предвидению тип. Если говорить про арифметические типы, то это дает возможность иметь шестнадцать различных арифметических типов (два в четвертой степени); должно быть достаточно, правда? К сожалению, у нас имеются NULL и не-NULL, которые забирают два значения кода. Позже мы добавили поддержку Kanji, для чего резервировалось два байта на NULL и по два байта на не-NULL. Итак, для каждого числового типа трибовалось четыре кода. Потом, мы имели INTEGER и SMALL INTEGER, которые вместе отбирали восемь кодов. Когда мы приводили код к промышленному виду, нам пришлось добавить DECIMAL и FLOATING POINT. Были задействованы все шестнадцать кодов. К сожалению, как только код вышел за пределы лаборатории, заказчики запросили короткие плавающие числа, чтобы экономить дисковую память, а некоторые захотели 16-байтовые плавающие числа и 31-байтовые DECIMAL для обеспечения большей точности. Слишком много для остатка от деления на четыре!



Как я говорила раньше, я всегда восхищалась всеми людьми из System R. Я думаю, что они были большими выдумщиками, и не только по поводу алгоритмов и выполнения всей громадной работы; они были также очень хороши в созидании, в придумывании таких вещей, как, например, образование прилагательного от таких слов как "Search Argument": sargable. Когда я разговаривала с заказчиком, то всегда говорила: "Этот предикат - sargable". Они смотрели на меня и говорили: "Что?"

Джим Грей

: Теперь у всех есть такие предикаты: Sybase и Oracle ...

Жозефин Ченг

: Да, и заказчики старательно искали смысл этого слова в словаре. А те люди, которые писали руководства - наши ребята из ID - не любили это слово. Они назвали это предикатом Типа 1; это означало, что он может быть обработан менеджером данных; предикат Типа 2 - RDS - мне это не нравилось; мне хотелось называть такие предикаты sargable.

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

Боб Йост

: Каковы были ваши инструкции? Говорили ли вам брать в основном RDS, потому что у вас был другой менеджер данных? Вы не собирались применять соответствующую подсистему из System R, но вы использовали в качестве наметки верхнюю половину технологии System R. Вы использовали ее как источник идей или смотрели на код и пытались транслировать его? Когда они обратились в Эндикотт, то там сказали: "Берите код. Транслируйте его; даже не задумывайтесь". Но у вас, должно быть, были другие инструкции.

Жозефин Ченг

: Ну, наши инструкции состояли в том, чтобы сделать его работающим. [смеется] Первое, что мы делали, - старались понять его; я думаю, что контактировала с каждым присутствующим здесь человеком: Марио, Пат, Дон - стараясь разобрать и понять, что делают программы. Для нашего первого выпуска мы должны были преобразовать этот код таким образом, чтобы он работал с нашим кодом системы: менеджером памяти, трассировкой, учетом - вы знаете, со всеми компонентами производственной системы. Мы также старались в первом выпуске добавить некоторые возможности, но реально не так уж и много - только то, что требовалось для коммерческого использования. Так что мы добавили числа с плавающей точкой и десятичные числа. В это время я взялась за оптимизатор, Джерри Бейкер (Jerry Baker) - за ASLGEN и Ник Номм (Nick Nomm) - за ODEGEN. Тогда машинное время стоило больше заработной платы, поэтому мы работали по субботам и воскресеньям. Мы втроем занимали весь этаж в субботу и воскресенье. Вы выполняли всю работу над RDS, и у Джерри была идея, что нам следует заняться поддержкой симметричных представлений. Это означало, что если вы выбираете что-либо через представление, то должны получить код ошибки при попытке вставить что-либо в область действия этого представления. И мы добавили функцию симметричных представлений в первый выпуск. Так что цель первого выпуска заключалась в том, чтобы получить работающую систему с минимальным добавлением функций и как можно скорее ее выпустить.



Джон Науман

: Было много аналогичных вещей, которые делались в Эндикотте; например, трансляция PL/1 в PL/S; мы должны были это сделать.

Жозефин Ченг

: Это уже было сделано в Эндикотте.

Джон Науман

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

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

: Мы были вынуждены переделывать, переделывать и переделывать, потому что постепенно понимали, в чем нуждается код System R. Я много раз перестраивал PTREE.

Жозефин Ченг

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

К. Мохан

: Смотрели ли вы видеоленты в процессе выполнения этой работы?

Жозефин Ченг

: Да. Кроме того, мы снимали на видео каждого из группы RDS, кто приходил в STL и читал нам лекции. Народ в Алмаден был очень склонен к сотрудничеству. Мы всегда получали ответы на все задаваемые вопросы, и мы всегда незамедлительно получали требуемую помощь.

Джон Науман

: Я знаю, что когда мы принимали решение работать с RDS, то большое беспокойство вызывало отсутствие людей из System R, и это одно из обстоятельств, которое очень волновало нас с Доном в дополнение ко всему, что было связано с MVS, и которое на самом деле никогда не проявилось. Я согласен с тем, что сказала Жозефин: если бы мы начали делать с нуля нашу собственную вещь, она могла бы получиться, но могла бы и не получиться. Завершающая часть могла бы быть сделана в тех же самых временных границах, но могла бы и быть сделана, но определенно большее время потребовалось бы для получения прототипа и утверждения того, что мы делали. Так что, я думаю, что в этой области System R нам сильно помогла.

(65) Замечание Роджера Миллера: "Насколько я помню, HOP в System R - это High Performance Optimizer".

(66) OLTP означает Online Transaction Processing.

(67) В RSS поддерживалась возможность простого поиска: можно было специфицировать "аргумент поиска" (SARG) в виде простого сравнения в канонической форме (например, зарплата больше константы), и RSS выполняла поиск по указанному пути. Это позволяло увеличить эффективность. Для того, чтобы можно было воспользоваться этой возможностью, программное обеспечение более высокого уровня должно было распознавать ситуации, в которых можно было использовать SARG. Если оператор SQL содержал предикат, соответствующий модели SARG, то этот предикат назывался sargable.

(xi) Здесь какая-то путаница, которую я не стал править. Используемый в оригинале оборот "modulo" four означает остаток от деления на четыре, который при традиционной интерпретации может иметь значения 0, 1, 2 и 3. Т.е. на самом деле при этом используются не четыре, а два разряда. Чтобы их было четыре, нужно использовать modulo sixteen. (Прим. переводчика.)

Страницы: 8

Esvel

Дон Слац

: Я полагаю, что в начале 1981 г. Капали [Эсваран] (Kapali Eswaran) говорил о том, что надо бы сделать нечто. У него было некоторое дело, которое исчезло в феврале или марте. Мы с Роджером [Бемфордом] встретились на ланче с несколькими людьми, которых он пытался надуть, и ...

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

: ... MDS???, правильно?

Дон Слац

: Нет, это была вторая. Первой была ... Итак, это все прошло, и где-то в августе или сентябре 1981 г. у него появился другой проект с этой компанией в Бостоне, MDS, которая, по-существу, хотела многопользовательскую RSS. Рон Ревель (Ron Revelle), который ушел в 1980 г., поступил на работу в Britton-Lee и работал над машиной баз данных. Он пришел туда как человек от аппаратуры, хотя на самом деле был специалистом по программному обеспечению. На самом деле, он работал с Капали в System D, и поэтому они знали друг друга достаточно хорошо. Он хотел сделать больше в машине Britton-Lee: больше средств аппаратного ускорения, а начальство Britton-Lee этого не хотело, поэтому он захотел заняться этим где-нибудь еще объединился с Капали. Так что исходный план Esvel состоял в том, чтобы сделать улучшенную машину баз данных Britton-Lee. Присоединились Роджер и Игнатиус [Динг] (Ignatius Ding). Итак, мы собрались в 1981 г. и ... В значительной степени мы оставались в рамках той же технологии - упреждающая запись в журнал; массивное чтение, поскольку это была машина баз данных, поэтому она была реально основана на принципах клиент-сервер. Потоки данных в оптимизаторе, поскольку композиция представлений была слишком сложна, и много других соображений. Рон погиб от несчастного случая, и на этом работа над аппаратурой закончилась. Мы продолжали работать еще около года и получили от этого предприятия некоторые деньги. Я полагаю, что они ничего не получили, не так ли? Такие люди никогда ничего не получают.

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

: Все остаются в дураках. [смеется]

Дон Слац

: Я думаю, Роджер ушел в 1983 г.

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

: Да, должно быть так.

Дон Слац

: В конечном счете компонент RSS для VM был получен за девять месяцев после начала проекта в пустом офисе в Кемпбелле (Campbell). А несколько месяцев спустя появилась версия для MVS.

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

: Ты имеешь в виду ??? - да, некоторый эквивалент RSS.

Дон Слац

: Верно.

К. Мохан

: Это купила HP, не так ли?

Дон Слац

: HP это купила, и это превратилось в ALLBASE.

Джим Грей

: Инвестором была компания Tektronix.

Дон Слац

: Итак, мы подписали контракт с HP в начале 1984 г., и потом обстоятельства сильно изменились, шестеро наших ушло, а потом еще семь и восемь - и HP приобрела это и назвала ALLBASE. В конце концов, компания была продана ...

Джим Грей

, К. Мохан: Cullinet. [IDMS/SQL]

Дон Слац

: Франко был там в течение трех месяцев в конце 1983 или начале 1984 г.

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

: И тогда у меня были незначительные конфликты с Капали.

Дон Слац

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

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

: Я думал, у тебя было интервью в Oracle.

Дон Слац

: Ну, после того, как я получил работу у Джона, Боб Майнер (Bob Miner) позвонил мне и сказал: "Мы потеряли Ваше резюме, мы действительно заинтересованы. Приходите в любом случае". Я пришел, и мы говорили с ним некоторое время, и я провел несколько часов с Ларри Эллисоном, что было интересно. Во время разговора я упомянул, что одно время работал над производительностью. А в это время Oracle был раскритикован по результатам прогонов Висконсинского тестового набора (Wisconsin benchmark), и Ларри неожиданно прекратил говорить об интервью, залез в свой большой деревянный письменный стол и вытащил все эти листинги. Он сказал: "Мы все это зафиксировали" и показал мне все результаты прогонов Висконсинского тестового набора. Мы разговаривали и разговаривали ... Потом я сказал: "Хорошо, но на самом деле я решил идти в Tandem". Он сказал: "Не ходите туда. Идите сюда; разбогатеете". [смеется]

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

: Эллисон интервьюировал меня, когда я уходил из Esvel. Он сказал: "Если Вы пойдете сюда, то больше не будете иметь никаких проблем с деньгами; я обещаю".

Джим Грей

: Джон, не хочешь ли ты рассказать про Tandem?

Джон Науман

: Конечно.

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

: Дон, были ли когда-нибудь какие-нибудь иски акционеров Esvel?

Дон Слац

: Да, позже. Процесс длился несколько лет, и окончательное соглашение включало предписание о неразглашении.

Майк Блазген

: Я всегда считал, что Франко перешел туда в качестве двойного агента. Ведь он пришел в Esvel, а потом ушел и утянул с собой нескольких человек?

Джим Грей

: Да, мы почти потеряли Андреа Борра, но в последнюю минуту она изменила решение.

Дон Слац

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

Функции по сравнению с методами

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

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

И функции, и методы могут быть написаны на SQL (с использованием вычислительно полных операторов SQL/PSM) или на любом из нескольких более традиционных языков программирования, включая Java.

Функциональная и точечная нотации

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

WHERE emp.salary > 10000

а в других ситуациях может быть более естественной функциональная нотация:

WHERE salary (emp) > 10000

В SQL:1999 поддерживаются обе нотации; в действительности, они определяются как синтаксические вариации одного и того же -- если "emp" является сущностью хранения (например, столбцом или переменной) с объявленным типом некоторого структурного типа с атрибутом, именуемым "salary" … или существует функция с именем "salary" с единственным аргументом, тип данных которого является (соответствующим) структурному типу данных emp.

В этому случае методы являются немного менее гибкими, чем функции: Для вызовов методом может использоваться только точечная нотация -- по крайней мере, для целей указания особого аргумента. Если метод salary был бы методом, тесно связанным с типом, скажем, employee, который, в свою очередь, был бы объявленным типом столбца emp, то метод можно было бы вызвать только с использованием конструкции

emp.salary

В другом методе, скажем, give_raise, могут комбинироваться точечная и функциональная нотации:

emp.give_raise (amount)

Информация на Web

American National Standards Institute (ANSI)

International Organization for Standardization (ISO)

JTC1 SC32 - Data Management and Interchange

National Committee for Information Technology Standards (NCITS)

NCITS H2 - Database

Informix

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

: Informix.

Джим Грей

: Informix. Я знаю про Informix немногое; я не знаком с историей компании, поэтому не думаю, что мог бы много сказать. Кто-нибудь знает историю Informix?

Том Прайс

: Единственное, что я слышал, это то, что по слухам этот их последний продукт действительно довольно хорош.

Джим Грей

: Это так. На самом деле, я знаком с их текущими продуктами. Я не знаю истории. Я знаю, что когда Tandem переориентировалась на UNIX, они сменили веру; не знаю точно, но, может быть, Дон [Слац] был среди тех, кто сменил веру и общался с ребятами из Informix.

Том Прайс

: И я тоже.

Джим Грей

: И ты? После этого ходили слухи, что эти ребята оказались не очень информированными о том, как реально делать эти вещи.

Том Прайс

: Да, например, они не знали, как делать блокировки на уровне записей, так что Франко им кое-что рассказал, и они, по всей видимости, пошли и сделали это. [смеется]

Майк Блазген

: Франко поступил в соответствии с традициями IBM, где рассказ о том, как что-то сделать, не чреват риском, что это будет действительно сделано. [смеется]

Джим Грей

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

Майк Блазген

: Всем спасибо.

Конец

(75) Боб Инглс умер 22 июня 1995 г. Замечание Роджера Миллера: "Боб был авторитетом в области стандартов SQL; он был автором исходного документа "SQL Control Document", который обеспечил основу стандартов SQL ANSI/ISO. Он был представителем DB2 в SQL Language Council с самого начала его существования, автором многих статей, а также он обеспечивал консультации сообществу SQL по всему миру. Он был проектировщиком многих средств DB2, включая ссылочную целостность, поддержку кодовых страниц и наборов символов, поддержку временных типов данных, а также последнюю работу в связи с SQL'92. Во время всей его карьеры в IBM и даже в последнее время, когда его болезнь прогрессировала, его преданность DB2 вдохновляла многих из нас. Он внес ключевой вклад в успех DB2, и нам будет очень его не хватать".

(76) ODBC обозначает Open Database Connectivity.

(77) TDS обозначает Tabular Data Stream.

(78) DRDA обозначает Distributed Relational Database Architecture.

(79) Microsoft Corporation. ODBC 2.0 Programmer's Reference and SDK Guide. Microsoft Press (1994).

(xii) ANSI/ISO/IEC 9075-3-1995. Information Technology - Database Languages - SQL - Part 3: Call-Level Interface (SQL/CLI). (Прим. переводчика.)

(xiii) ANSI/ISO/IEC 9075-4-1996. Information Technology - Database Languages - SQL - Part 4: Persistent Stored Modules (SQL/PSM). (Прим. переводчика.)

(xiv) После выпуска консорциумом OMG (www.omg.org) спецификаций CORBA-2 все большее распространение получает определенный в этом стандарте протокол IIOP. (Прим. переводчика.)

(xvi) В 1996 г. X/Open и Open Software Foundation (OSF) образовали консоциум . (Прим. переводчика.)

(xvii) С первого января 1997 г. компания NCR (www.ncr.com) снова является независимой. (Прим. переводчика).

(80) IBM Corporation. Distributed Relational Database Architecture Reference, SC26-4651.

(81) R. Epstein and P. Hawthorn. "Design Decisions for the Intelligent Data Base Machine". Proc. National Computer Conference, Anaheim, California (May 1980).

10

Использование REF-типов

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

В SQL:1999 обеспечивается синтаксис для "перехода по ссылке" для доступа к атрибутам значения структурного типа:

SELECT emps.manager -> last_name

Указательная нотация (->) применяется к значению некоторого REF-типа и позволяет затем "перейти" к идентифицируемому значению ассоциированного структурного типа -- которое, конечно, является строкой типизированной таблиц, входящей в область видимости REF-типа. Этот структурный тип является и типом, ассоциированным с REF-типом столбца manager таблицы emps, и типом этой другой таблицы (имя которой не требуется и не содержится в приведенном выражении). Однако этот структурный тип должен содержать атрибут с именем last_name, и типизированная таблица, таким образом, содержит столбец с таким именем.

Истоки

Уже несколько лет вы слышите и читаете о грядущем стандарте, который все называют SQL3. Предназначенный для того, чтобы стать существенной модернизацией текущего стандарта языка SQL второго поколения, повсеместно называемого SQL-92 в соответствии с годом публикации, SQL3 первоначально планировался к выпуску в 1996 г. ... но дела шли не так, как планировалось.

Возможно, вы знаете, что SQL3 характеризуется как "объектно-ориентированный SQL" и является основой нескольких объектно-реляционных систем управления базами данных (включая, среди прочих, ORACLE8 компании Oracle, Universal Server компании Informix, DB2 Universal Database компании IBM и Cloudscape компании Cloudscape). Широко распространена точка зрения, что это хорошо, но имеется и обратная сторона: работа заняла около семи лет, вместо планировавшихся трех-четырех.

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

Литература

[1] ISO/IEC 9075:1999, Information technology -- Database Languages -- SQL -- Part 1: Framework (SQL/Framework), will be published in 1999.

[2] ISO/IEC 9075:1999, Information technology -- Database Languages -- SQL -- Part 2: Foundation (SQL/Foundation), will be published in 1999.

[3] ISO/IEC 9075:1999, Information technology -- Database Languages -- SQL -- Part 3: Call-Level Interface (SQL/CLI), will be published in 1999.

[4] ISO/IEC 9075:1999, Information technology -- Database Languages -- SQL -- Part 4: Persistent Stored Modules (SQL/PSM), will be published in 1999.

[5] ISO/IEC 9075:1999, Information technology -- Database Languages -- SQL -- Part 5: Host Language Bindings (SQL/Bindings), will be published in 1999.

[6] New Standard for Stored Procedures in SQL, Andrew Eisenberg, SIGMOD Record, Dec. 1996

Спецификации SQL будут доступны в Соединенных Штатах в

American National Standards Institute

Attn: Customer Service

11 West 42nd Street

New York, NY 10036

USA

Phone: +1.212.642.4980

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

International Organization for Standardization

1, rue de Varembe

Case postale 56

CH-1211 Geneve 20

Switzerland

Phone: +41.22.749.0111

Мортон Астрахан

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

: Мортон был действительно необычным человеком. Я впервые встретился с Мортоном, когда перебрался в Калифорнию вместе с Реем Бойсом, Фрэнком Кингом, Верой Ватсон и некоторыми другими людьми в 1973 г. Это было большое вливание новых людей в среду Сан-Хосе, где велась подготовка проекта, и конечно, на проект повлияло прибытие новичков. У разных людей были разные точки зрения по поводу проекта. Термин "Йорктаунская мафия" обозначает одну из точек зрения; Мортон никогда не использовал этот термин. Отношение Мортона к вновь прибывшим, выражалось следующими словами: "Добро пожаловать в Калифорнию. Могу ли я что-нибудь сделать, чтобы Вы чувствовали себя как дома?" Поскольку не все чувствовали себя таким образом, было действительно приятно иметь рядом Мортона, который знал все ходы и выходы и помогал нам найти жилье, места для покупок и для ночных развлечений. Было очень приятно ощущать, что нас опекают старожилы. Я говорю это, хотя сам уроженец Сан-Хосе.

У Мортона была хижина в горах, которую он назвал Сириндипити (Serendipity). Как вы знаете, "серендипити" означает вид неожиданного хорошего результата. Я никогда точно не выяснял, почему хижина Мортона называлась Сириндипити, но эта хижина была очень важной вещью для Мортона и одним из тех мест, куда он просто должен был пригласить всех выходцев из Нью-Йорка, по одному за раз, на свою гору во время уикенда. Так что мы пошли туда и взяли с собой маленькую дочь, и это было прекрасное место, и Мортон действительно наслаждался, разделяя его с людьми. Мортон говорил, что у него есть муза, которая живет в Сириндипити, и как только в нашем проекте появлялась какая-нибудь техническая проблема, заставляющая всех ломать голову, Мортон должен был исчезнуть на несколько дней, отправиться на гору и посоветоваться со своей музой. Много раз он возвращался с решением проблемы. Я считал, что это замечательно. Когда Мортон исчезал, я всегда с нетерпением ждал, что он скажет по возвращению.

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

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

Мортон ушел на пенсию где-то в середине 1980-х - я не помню точной даты - и вскоре после этого скончался - вероятно, в 1986 г. или около этого.

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

(1) Special Issue: Data-Base Management Systems. ACM Computing Survey 8, 1 (March 1976).

(2) D.D. Chamberlin, M.A. Astrahan, M.W. Blasgen, J.N. Gray, W.F. King, B.G. Lindsay, R. Lorie, J.W. Mehl, T.G. Price, F. Putzolu, P.G. Selinger, M. Schkolnick, D.R. Slutz, I.L. Traiger, B.W. Wade and R.A. Yost. "A History and Evaluation of System R" CACM 24, 10 (October 1981) pages 632-646.

(3) J.N. Gray and V. Watson. A Shared Segment and InterProcess Communication Facility for VM/370. IBM Research Report RJ1579. San Jose, California (May 1975).

Страницы: 1

Народ из System R покидает каньон

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

: Хорошо, мы обсудили, что происходило с DB2. Но было множество людей, которые покинули IBM и делали разные вещи в других компаниях. Я хотела бы разобрать историю Esvel, Tandem и Oracle. Дон, не хочешь ли ты немного рассказать про Esvel?

К. Мохан

: Богачи, не правда ли? [смеется]

Трудно точно провести грань, говоря

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

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

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

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

WITH RECURSIVE Q1 AS SELECT … FROM … WHERE …, Q2 AS SELECT … FROM … WHERE … SELECT … FROM Q1, Q2 WHERE …

Мы уже упоминали локаторы как значение на стороне клиента, которое может представлять LOB-значение, хранимое на стороне сервера. Таким же образом локаторы могут быть использованы для представления ARRAY-значений, если принять во внимание тот факт, что (подобно LOB'ам) ARRAY-значение часто может быть слишком велико, чтобы обычным образом передаваться между приложением и базой данных. Локаторы также могут использоваться для представления значений определяемых пользователем типов -- обсуждаемых далее -- которые тоже могут потенциально быть большими и громоздкими.

Наконец, в SQL:1999 добавлено понятие точек сохранения (savepoints), реализованных во многих приложениях. Точка сохранения немного похожа на подтранзакцию в том смысле, что приложение может выполнить откат действий, выполненных после начала точки сохранения, не откатывая все действия транзакции целиком. SQL:1999 допускает выполнение операций ROLLBACK TO SAVEPOINT и RELEASE SAVEPOINT, которыет во многом действуют подобно фиксации подтранзакции.

Новые предикаты

В SQL:1999 имеются три новых предиката, один из которых мы будем рассматривать среди объектно-ориентированных свойств. Другими двумя являются предикат SIMILAR и DISTINCT.

С первой версии стандарта SQL поиск через символьные строки был ограничен очень простыми сравнениями (типа =, > или <>) и довольно рудиментарными возможностями сопоставления с образцами предиката LIKE:

WHERE NAME LIKE '%SMIT_'

В данном случае значения столбца NAME сопоставляются со значениями, включающими ноль или более символов перед четырьмя символами 'SMIT' и в точности один символ за ними (такими, как SMITH или HAMMERSMITS).

В связи с пониманием того, что приложениям часто требуются более усложненные возможности, которые, тем не менее, не совпадают с полным набором операций над текстами, в SQL:1999 был введен предикат SIMILAR, где в образцах сопоставления можно использовать регулярные выражения в стиле UNIX. Например:

WHERE NAME SIMILAR TO ' (SQL- (86|89|92|99) ) | (SQL (1|2|3))'

Этот предикат произвел бы сопоставление образца с различными названиями, присваивавшимися когда-либо стандарту SQL. Слегка неудачно то, что регулярные выражения, используемые в предикате SIMILAR, не совсем следуют синтаксису регулярных выражений UNIX, но некоторые символы UNIX уже используются в SQL для других целей.

Другой новый предикат DISTINCT очень похож по своему действию на обычный предикат SQL UNIQUE; важным отличием является то, что два неопределенных значения считаются неравными одно другому и поэтому удовлетворяют предикату UNIQUE, но это желательно не для всех приложений. Предикат DISTINCT рассматривает два неопределенных значения как неотличающиеся одно от другого (хотя, конечно, они не являются равными и в то же время не являются неравными), и поэтому два неопределенных значения не удовлетворяют предикату DISTINCT.

Новые типы данных

В SQL:1999 имеется четыре новых типа данных (хотя для одного из них имеются некоторые опознаваемые варианты). Первым из этих типов является тип LARGE OBJECT, или LOB. Это тип с вариантами: CHARACTER LARGE OBJECT (CLOB) и BINARY LARGE OBJECT (BLOB). CLOB'ы ведут себя во многом подобно символьным строкам, но ограничены тем, что запрещено их использование в предикатах PRIMARY KEY и UNIQUE, в FOREIGN KEY, а также в сравнениях, отличных от чистых равенства или неравенства. Для BLOB'ов действуют аналогичные ограничения. (Косвенным образом, LOB'ы нельзя также использовать в разделах GROUP BY и ORDER BY.) Обычно приложениям не требуется пересылать весь LOB целиком в базу данных и из базы данных (конечно, после исходного их размещения); следует манипулировать LOB-значениями через специальный тип на стороне клиента, называемый LOB-локатором. В SQL:1999 локатор - это уникальное двоичное значение, которое действует как вид суррогата значения, сохраняемого в базе данных; локаторы могут использоваться в операциях (таких, как SUBSTRING) без привлечения накладных расходов для пересылки всего LOB-значения через интерфейс клиента и сервера.

Другим новым типом является тип BOOLEAN, который дает возможность в SQL непосредственно записывать истинностные значения true, false и unknown. Сложные комбинации предикатов можно также выразить способами, которые в чем-то более дружественны к пользователям, чем этого можно добиться обычными методами реструктуризации:

WHERE COL1 > COL2 AND COL3 = COL4 OR UNIQUE (COL6) IS NOT FALSE

В SQL:1999 имеются также два новых составных типа: ARRAY и ROW. Тип ARRAY позволяет хранить коллекции данных непосредственно в столбце таблицы базы данных. Например, определение

WEEKDAYS VARCHAR (10) ARRAY[7]

позволило бы хранить названия всех семи дней недели в одной строке базы данных. Означает ли это, что SQL:1999 допускает базы данных, не удовлетворяющие первой нормальной форме? Действительно, допускает, в том смысле, что разрешаются "повторяющиеся группы", запрещаемые первой нормальной формой. (Однако некоторые утверждают, что тип ARRAY в SQL:1999 всего лишь допускает хранение информации, которую можно декомпозировать, во многом подобно тому, как функция SUBSTRING может декомпозировать символьные строки -- и поэтому в действительности не противоречит духу первой нормальной формы.)

Тип ROW в SQL:1999 является расширением (анонимного) строчного типа, который всегда был в SQL и от наличия которого язык зависел. Этот тип обеспечивает разработчиков баз данных дополнительной возможностью хранения структурированных значений в одном столбце базы данных:

CREATE TABLE employee ( EMP_ID INTEGER, NAME ROW ( GIVEN VARCHAR (30), FAMILY VARCHAR (30) ), ADDRESS ROW ( STREET VARCHAR (50), CITY VARCHAR (30), STATE CHAR (2) ), SALARY REAL )

SELECT E.NAME.FAMILY FROM employee E

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

В SQL:1999 добавлена еще одна связанная с типами данных возможность, называемая "индивидуальными типами" (distinct types). Учитывая, что в общем случае маловероятно, что в приложении потребуется непосредственно сравнивать, например, размер обуви служащего со значением его или ее IQ, программистам SQL позволяется объявить типы SHOE_SIZE и IQ, основанные на INTEGER, и запрещается непосредственное перемешивание этих двух типов в выражениях. Так, выражение вида

WHERE MY_SHOE_SIZE > MY_IQ

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

SET MY_IQ = MY_IQ * 2

Взамен этого в программах должно явно выражаться продуманное намерение допускать такое смешение:

WHERE MY_SHOE_SIZE > CAST (MY_IQ AS SHOE_SIZE)

SET MY_IQ = MY_IQ * CAST (2 AS IQ)

В дополнение к этим типам в SQL:1999 также введены определяемые пользователями типы, но они попадают в список объектно-ориентированных свойств.

Объектная ориентация

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

Некоторые из возможностей, относящихся к этой категории, были впервые определены в стандарте SQL/PSM, опубликованном в конце 1996 г. -- конкретно, поддержка функций и процедур, вызываемых из операторов SQL. В SQL:1999 это средство, называемое вызываемыми из SQL подпрограммами, развивается за счет добавления третьего класса подпрограмм, именумых методами, к рассмотрению которых мы скоро перейдем. Мы не хотели бы копаться здесь в вызываемых из SQL функциях и процедурах, и отсылаем читателей к более раннему выпуску SIGMOD Record [6].

Объекты … в конце концов

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

Чтобы получить незначительную характеристику, которая позволила бы SQL обеспечивать объекты, требуется наличие некоторой разновидности идентификации, которую можно применять в разных ситуациях. В SQL:1999 эта возможность обеспечивается за счет того, что разработчикам базы данных разрешается указывать, что некоторые таблицы определяются как "типизированные таблицы" … т.е. их определения столбцов порождаются из атрибутов структурного типа:

CREATE TABLE empls OF employee

Такие таблицы содержат один столбец для каждого атрибута определяющего структурного типа. Функции, методы и процедуры, определенные для оперирования экземплярами типа, теперь применимы к строкам таблицы! Тогда строки таблицы являются значениями -- или экземплярами -- типа. Каждой строке присваивается уникальный идентификатор, который ведет себя подобно OID (идентификатор объекта) … он уникален в пространстве (т.е. внутри базы данных) и во времени (жизни базы данных).

SQL:1999 обеспечивает специальный тип, называемый REF-типом, значениями которого являются уникальные идентификаторы. Данный REF-тип всегда ассоциируется в указанным структурным типом. Например, если мы собирались определить таблицу, содержащую столбец с именем "manager", значения которого являются ссылками на строки типизированной таблицы служащих, то это выглядело бы подобно следующему:

manager REF (emp_type)

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

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

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 и т.д. Теперь это основная сила в мире баз данных. И я думаю, что любого в этом мире сводит с ума то, что этот продукт очень дешев. Порядка пяти тысяч долларов за сервер по сравнению с сотней тысяч долларов. Этот сервер в состоянии выполнять сотни транзакций в секунду. Жуть. Пат, я ...?

Перерыв на ланч

Майк Блазген

: Исходно мы планировали после обеда переключить наше обсуждение на то, что происходило после всей работы в Строении 28; исследования, которые производились после нас, а затем мы собирались перейти к разговорам о продуктах. Кто выиграл, разделяемых 10K и подобных вещах. Но мы отстали утром, и я думаю, что нам следовало бы обсудить некоторые вещи, связанные со взаимодействиями исследовательской лаборатории Сан-Хосе и других частей IBM, которые были успешны или неуспешны в смысле продвижения этого продукта за пределы лаборатории. Я уже утверждал раньше, что публикации во многом способствовали тому, что IBM стала готовой к тому, чтобы вывести системы за пределы лаборатории и перевести в разряд продуктов. Конечно, полученными в конце концов продуктами были система SQL/DS, которая остается действующим продуктом и все еще содержит много кода System R, и DB2, которая напрямую вообще не содержит код System R, но System R оказала основное влияние на ее разработку. И потом имеется много других производных System R, разработанных другими компаниями. Джим мог бы рассказать нам о том, как компания Tandem позаимствовала все наши хорошие идеи, если это так на самом деле, и о том, что сделала компания Oracle. Но я хотел бы в особенности сосредоточиться на шагах, сделанных до 1981 г., которые привели к выпуску IBM первого набора продуктов. Прежде всего, производился обмен людьми между Сан-Хосе и группой разработчиков, которая первоначально базировалась в Пало-Альто, а затем перебралась в Санта-Тереза, когда там достроили здание. Что было последствием этого? Ты ведь провел там год, Ирв?

Ирв Трейджер

: Мы с Франко были направлены на временную работу в Пало-Альта для участия в проекте FS. Позже мы оба получили назначение в лабораторию Санта-Тереза, где принимали участие в начальной стадии работы, когда принимались ключевые решения, приведшие к возникновению DB2.

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

: Потом прибыл Джим.

Майк Блазген

: Правильно, потом в Пало-Альто приехал Джим, и вы провели там год.

Джим Грей

: Да. В процессе мы перебрались в Санта-Тереза. Так что закончил я в Санта-Тереза.

Майк Блазген

: И ты работал над Eagle?

Джим Грей

: Да, тогда это называлось VSS. В группу входил Джон Науман, и Томас Уорк (Thomas Work) был менеджером; [Стив] Вейк являлся менеджером Томаса. Отвечал за это Энди Хеллер (Andy Heller). В течение шести месяцев мы собирались построить продукт, который мог бы заменить IMS и делал все, что делает System R. В то время Энди был еще более агрессивным.

Майк Блазген: По этому поводу у меня есть история про Энди Хеллера. В том время, когда вы были там, мы с Томом Прайсом писали статью "How Database Systems Recover", которую собирались опубликовать, но так и не сделали этого. Мы старались задокументировать, как работает восстановление в нескольких существующих системах, а затем поразмышлять о более общих вещах, приводящих к терминам "no-force", "steal/no-force", "no-steal/force"; все эти вещи частично происходили из выполняемой нами работы. Мы хотели написать, как работает VSS. Поэтому, увидев как-то Энди в здании лаборатории, мы подошли к нему и спросили: "Как в точности это работает в данной ситуации?". Энди сказал: "Бла, бла, бла", мы записали, и он ушел. Потом мы уселись и попробовали написать это в том виде, как смогли понять. И не смогли. Мы дошли до такой ситуации, в которой алгоритм не работает. И мы дождались новой встречи с Энди, принесли ему свои записки и сказали, что это не работает. А он сказал: "Нет, нет, нет; это не то, что я имел в виду; возможно, это то, что я сказал". Мы были вынуждены встречаться с ним семь или восемь раз и так и не смогли выяснить ... однако, должен сказать, было изобретено семь или восемь неработающих алгоритмов. [смеется] Это была фантастика.

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

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



Джон Науман

: Это остановило взаимодействия. [смеется]

Джим Грей

: После того, как я ушел, пришел Франко. И Франко провел там, я думаю, около ...

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

: Почти три года.

Джим Грей

: Ну да, ты провел там год, и наступило время возвращаться. Он сказал: "Мне пора уезжать", а они сказали: "Нет, ты не можешь этого сделать!". И он сказал: "Хорошо, я буду на вас работать. Если мы не должны доводить процесс Санта-Тереза до конца, я останусь. Но это должна быть только работа: никаких отчетов, никаких рецензий. Раз в месяц я буду говорить вам о состоянии работы." Я могу в чем-нибудь ошибаться ...

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

: Да.

Джим Грей

: И они сказали: "Иди молоть песок." И он вернулся в Сан-Хосе. Совершенно внезапно через месяц или два ты опять оказался в Санта-Тереза. И там была группа, включающая [Дона] Хэдерли ([Don] Haderle), Боба Гумаера (Bob Gumaer) и ...

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

: Посмотрите, это было с 1977 по 1979 гг., около трех лет.

Джим Грей

: Значит, в 1978 г. ...

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

: Да, имелись незначительные конфликты по части управления всем этим. [смеется]

Джим Грей

: Франко хотел преобразовать одиннадцатифазный процесс в двух- или трехфазный.

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

: Ну, лаборатория Санта-Тереза была действительно парализована. У них была эта большая группа, и они непрерывно меняли название проекта. Сначала он назывался VSS, потом DS/1, потом Eagle, потом Ampersand, что было единственным симпатичным названием, поскольку Ampersand означает переменную в языке SCRIPT. Предполагалось, что эта система заменит все системы баз данных. Она должна была заменить IMS, обеспечить новые причудливые интерфейсы, обеспечить все виды совместимости. Имелись три компонента. Единственной выжившей частью являются System Services. Такие вещи как журнализация, восстановление и блокировки; это единственный компонент, который выжил в DB2. Имелся Data Communication Component, который полностью сошел на нет.

Джим Грей

: Подсистемы ввода/вывода; управление буфером.



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

: Нет, это было добавлено позже. И еще была Future Database System, которая прошла через ряд инкарнаций. На некоторое время это было расширение PL/1 Криса Дейта (Chris Date).

К. Мохан, Майк Блазген

: UDL.

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

: Представляйте себе это как систему баз данных с малым импедансом, если использовать современную объектную терминологию. И в течение некоторого времени это была система со многими лицами: у нее имелась иерархическая личность, реляционная личность, сетевая личность; к ней был привит DL/1. И все это происходило не слишком хорошо. Поэтому, когда присоединился к проекту, я решил, что имеется очевидная потребность в подсистеме, которая поддерживала бы все эти внешние интерфейсы. Я решил работать над подсистемой низкого уровня, которая поддерживала бы все эти интерфейсы. Это была подпольная работа, поскольку в это время управление в Санта-Тереза было очень ограничивающим; они действительно лишали тебя свободы. Итак, этот проект назывался Technology Evaluation (проверка техники). У него даже не было кодового названия IBM. Я имею в виду, что обычно каждый проект в Санта-Тереза должен был иметь имя, я не знаю, какого-нибудь языческого божества, какого-нибудь животного, какого-нибудь кровожадного животного. Но эта штука называлась просто Technology Evaluation, и только спустя некоторое время мы собрались и решили, продукт не может иметь такого названия, для заказчиков будет странно видеть ядро системы баз данных под названием Technology Evaluation. Оно было переименовано просто в Data Manager. Посмотрите, сколько людей работали над этим в начале. Жозефин Ченг работала над кэшем, Дик Крус (Dick Crus), Тим Малкемус (Tim Malkemus), Сид Корнелис (Sid Kornelis), Боб Гумаер, Минг Шен (Ming Shan) и Джейн Дуфти (Jane Doughty), которая в конце концов перешла в Sybase; она была единственной разбогатевшей в процессе этой работы.

Майк Блазген

: В связи с упомянутыми тобой вещами у меня имеется впечатление, что в Санта-Тереза делался собственный продукт; эта System R, если она относилась к делу, была источником программистов. Я имею в виду, что можно было нанять таких людей как Франко. Мы вели переговоры; взамен мы получили Боба Йоста. Я думаю, что это был хороший обмен. У меня есть вопрос: какую роль должна была играть System R?



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

: Ну, в течение долгого времени официальная позиция состояла в том, чтобы не принимать в расчет System R. Важно было разработать сетевую систему баз данных. Изо всех интерфейсов - я упоминал пять или шесть интерфейсов,- которые предполагалось поддерживать в этой экуменической системе, реальным интерфейсом предполагался сетевой; и конечно, это была не DBTG, это было нечто иное.

К. Мохан

: Это из-за Боба, как его имя?

Том Прайс

: Инглс (Bob Engles).

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

: Может быть, это был Боб Инглс; я не помню.

Джим Грей

: Это было культурно; это было потому, что все эти деньги приходили от IMS.

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

: Предполагалось, что IMS будет прививкой. Привить только часть кода. Итак, они дали нам спокойно работать около трех лет. Мы знали, что эта подсистема должна стать частью промышленной системы, поэтому мы старались писать хороший код и, в отличие от System R имели соглашение об именовании; мы старались применять хорошую технологию программирования.

Майк Блазген: Это привело к появлению серии компонентов, которые теперь являются частью DB2, это так?

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

: Да, я думаю, что большая часть продолжает существовать в DB2, а теперь мне бы хотелось услышать о том, что происходило после моего ухода.

Майк Блазген: Мне тоже, но давайте сначала завершим эту тему. Итак, эти компоненты были разработаны. Эти компоненты имели небольшое отношение к System R, не так ли?

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

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

Я был убежден, что другим основным интерфейсом, работающим поверх Data Manager - или Technology Evaluation, что одно и то же, - должен быть DL/1. И в действительности мы потратили треть кода и времени для написания специального кода в Data Manager для поддержки DL/1. Был реализован целый ряд хитростей для DL/1. К 1979 г. у нас был прототип, работающий в среде VM. Он обладал значительной функциональностью, и мы пропускали первые содержательные тесты на том, что позже стало называться DB2. Имелись регрессионные тесты физических баз данных DL/1. Это было достаточно интересно; DL/1 работал довольно хорошо.

50 Том Прайс позже работал в Отделении офисных продуктов.

51 Emerson Pugh. Building IBM. The MIT Press, Cambridge, Massachusets (1995).

52 Pugh, page 309.

Страницы: 5

Перестрелка в OK Corral

Джим Грей

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

Майк Блазген

: О, это совсем другая история. Для обсуждения запросов мы имеем целую сессию.

Джим Грей

: Нет, это стоит обсудить раньше.

Майк Блазген

: OK, давайте займемся этим; это хорошая тема, ты прав.

Джим Грей

: Был QBE, потом VS/QUERY и перестрелка в OK Corral; все это предшествует ...

Майк Блазген

: OK, давайте это сделаем. Бред, можешь ли ты справиться с QBE?

Бред Вейд

: Мне потребуется значительная помощь, поскольку по освященной веками традиции IBM мы имели группу System R, работающую над реляционными системами баз данных в Сан-Хосе, и мы имели Мойше Злуфа (Moshe Zloof), работающего над Query by Example - другой реляционной системой баз данных - в Йорктауне. Поэтому возникал вопрос, почему мы имеем в IBM две группы на противоположных побережьях, делающие в точности одно и то же. А точных данных о том, откуда появились Мойше и его группа и как они стартовали, у меня нет.

Майк Блазген: На самом деле, я знаю ответ и расскажу об этом только потому, что это интересно. В Йорктауне была группа, которая работала над некоторым проектом под названием Programming by Example. Идея состояла в том, чтобы можно было производить обработку бизнес-данных, таких как платежные ведомости, путем предоставления примера того, что требуется, да, это было нечто вроде получения похожего выходного результата. Если вы показывали системе заготовку программного обеспечения, которое хотели получить на выходе, она определяла, как получить его.

Джим Грей

: Модель RPG.

Майк Блазген

: Это было так: "Покажи мне, что ты хочешь получить на выходе и я определю, как получить это на основании доступных данных". Это никогда ни к чему не приводило. Знаете, что такое программирование по примеру на самом деле? Это реально произошло; это VisiCalc. Эта вещь наиболее близка к программированию по примеру, она очень близка, это именно то, о чем они думали. Но они никогда этого не получили, они никогда не получили VisiCalc. Но они получили нечто похожее, то, что называлось Query By Example. Это не программирование по примеру, но по крайней мере запросы по примеру. И идея состояла в том, чтобы можно было нарисовать картину ответа и сказать: "Вот ответ, которого я хочу", а затем система определяла как получить это и выдавала ответ. Это был Query By Example; Мойше Злуф был ключевой фигурой, а Петер де Джонг (Peter de Jong) - менеджером.

Бред Вейд: Query By Example был ранним графическим интерфейсом, если хотите, потому что можно было нарисовать картину таблицы на своем экране, и если хотелось "Salary = 10000", то нужно было бы написать "10000" в столбце Salary. И я думаю, что если были нужны люди с зарплатой больше 10000, нужно было бы написать в столбце Salary ">10000". Вместо раздела SELECT языка SQL нужно было написать "P." В столбце, к которому адресовался запрос. Я смутно помню игры в запросы с людьми из штата Злуфа, но по моим ощущениям простые вещи выражались на Query By Example просто, а сложные были невозможны; в то же время их можно было выразить на SQL.

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

Джим Грей

: Бред, я думаю, что до этого кое-кто полюбил QBE, и они на самом деле поставляли его.

Джим Мехл

: Как RPQ или что-то вроде этого.

Джим Грей

: Были люди в этой области, которым наравился QBE. Они рассказывали про ленточных библиотекарей, которые автоматизировали свои ленточные библиотеки с помощью этой системы, и Жене Триветт (Gene Trivett) наблюдал за этим и устранял некоторые проблемы, связанные с производительностью, и система получила неожиданное распространение по всей планете. У нее были очень верные приверженцы. Для каждого было очевидно, что система делает нечто замечательное. Это была программа для конечного пользователя. Поэтому возникали вопросы: "А почему бы нам не прекратить проект System R" или "Почему мы не развиваем эту вещь?". Я думаю, что Бобу [Джойллсу] эти вопросы задавались многократно.

Боб Джойллс: Группа VS/QUERY постоянно старалась взять все лучшее и из SQL, и из QBE, и позже это получилось. Но когда я управлял этой группой, нам определенно требовалось урегулировать все это. Но я никогда не участвовал в чем-либо, где QBE рассматривался бы как производственная замена SQL.



Джим Грей

: Так в чем же заключалась цель перестрелки?

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

: Я думаю, что это направлялось исследовательским управлением.

Майк Блазген

: Я расскажу вам, чем была перестрелка. Это было очень неприятное и интересное противоборство. Гомори беспокоил тот факт, что он серьезно инвестировал два проекта, в которых, как казалось, делаются примерно одинаковые вещи. Одним из наших аргументов было то, что у нас работают все эти сильные люди, такие как Франко и Джим, которые сделали RSS, а RSS был действительно хорошей вещью, действительно хорошим кодом, он до сих пор входит в SQL/DS; тот же самый код.

К. Мохан

: Примерно когда это происходило?

Майк Блазген

: У меня нет точной даты, но где-то в 1978 г., верно? Когда происходила перестрелка? 1978 г.? Гомори попросил Дика Кейса (Dick Case) произвести проверку работы. Дик Кейс привлек Ашока Чандру, который теперь возглавляет отделение Computer Science - он представлет собой поздний вариант Фрэнка Кинга - и еще одного человека; все они были незаинтересованными, но технически подготовленными людьми. Они поехали в Йорктаун и выучили все насчет QBE, а потом двинулись в Сан-Хосе, чтобы выучить все про System R, и я прочитал им длинную лекцию про то, как работает менеджер блокировок, как могут работать блокировки на основе Compare-and-Swap, как мы все это сделали и как можно реализовать Compare-and-Swap-Double. Дик Кейс был впечатлен, поскольку, видимо, именно он придумал Compare-and-Swap. Присутствовал Ашок, и обсуждался этот вопрос, можно ли реализовать QBE на SQL. Это был другой подход, если хотите, наш подход, который мы хотели применить в VS/QUERY и который заключался бы в том, что не следует писать QBE над интерфейсом RSS. Это означало бы наличие нескольких сред. Мы хотели иметь QBE как графический интерфейс, подчеркивая его сильные стороны - графику - и слабые стороны: XRM, отсутствие многопользовательского режима, плохое управление памятью и плохую производительность. Не было компилятора, только интерпретатор. Поэтому Ирв Трейджер выполнил гигантскую работу, трехмесячную работу, чтобы показать деталь за деталью, как можно отобразить QBE на SQL. Был спор относительного того, является ли язык QBE по-настоящему правильно специфицированным. В языке имелись двусмысленности, и у меня есть записи с собрания, на котором Петер де Джонг сказал: "Да, я не могу доказать, что вы не правы, но я уверен, что вы не правы. Я не приму вашего утверждения о том, что у нас есть двусмысленности, даже если вы задокументируете двусмысленности восемью разными способами". В любом случае, было показано, что это можно сделать. И эти ребята завершили там оценку системы, и одним из вопросом была производительность, поскольку мы утверждали, что наш способ реализации, помимо прочего, обеспечит гораздо лучшую производительность. Люди с дальнего востока сказали: "Нет, это неправильно, потому что речь идет о непредвиденных запросах, а для них больше подходит интерпретация". Они хотели программировать прямо над RSS.



Бред Вейд

: Спасибо, Майк. Мои воспоминания далеко не так глубоки. Я помню, что все скатилось к производительности. System R работала на одной из 3270 в терминальном зале. Мы исталлировали QBE под другим идентификатором пользователя и имели доступ к системе с другого терминала в терминальном зале. Мы вставляли запал; мы вводили некоторый SQL-запрос; я не помню, что он должен был делать. Тот же самый запрос задавался с помощью QBE, после чего выполнялась самая сложная часть работы: мы одновременно нажимали на клавиши ENTER и с секундомерами в руках следили за тем, какая система первой выдаст результат. Не помню, через тридцать секунд или через минуту тридцать секунд System R выдала результат, мы повернулись к другому терминалу и - увидели крах системы. После этого звезда System R взошла более высоко.

Майк Блазген

: Мы дали им возможность составить некоторые запросы, потому что они пришли ...

Брюс Линдсей

: Ты имеешь в виду, что они не могли завершить выполнение никакого запроса?

Майк Блазген

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

...

Джим Грей

: Наиболее убийственная разница в производительности заключалась в том, что Бред умел вводить текст, а человек, который отвечал на QBE, вводил двумя пальцами и с массой ошибок. [смеется] Так что, когда они говорили: "Следующий запрос", Бред делал "Жжжжж". [смеется]

Майк Блазген

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

???

: Это делалось на UFI?

Майк Блазген

: Да, мы использовали UFI против интерфейса QBE.

Джим Грей

: А что такое OK Corral?



Майк Блазген

: Терминальный зал, в котором была разработана RSS.

Бред Вейд

: После того, как все закончилось и наши визитеры уехали, кто-то - я не помню, кто - сделал табличку. Я думаю, на ней было написано "The OK Corral". И кто-то наклеил ее на дверь. Была такая картина, которую я смотрел в десятилетнем возрасте; знаменитый вестерн со стрельбой.

Ирв Трейджер

: Wyatt Earp, Doc Holiday и Hirsh Cohen. [смеется]

Джим Грей

: High Noon (Высокая луна).

Майк Блазген

: Итак, вот что произошло, и это было здорово, и мы всегда потом называли это перестрелкой в OK Corral. Проект QBE был продолжен как IUP, но эта система реально никогда нигде не работала; она не была существенно усовершенствована. В Санта-Тереза ее взять не захотели. DP, являющееся отделением продаж, которое поддерживало IUP, продолжало продавать ее, но без инвестиций.

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

: QMF.

Майк Блазген

: Прошу прощения. Да.

Роджер Миллер (Roger Miller)

: Даже в виде QMF это средство не стало слишком популярным.

Роджер Бемфорд (Roger Bamford)

: Мы клонировали его.

Майк Блазген

: Это интересно.

Пол МакДжонс

: Теперь это называется Microsoft Access. [смеется]

Майк Блазген

: Возможно, некоторая версия одержит победу.

К. Мохан

: Но другие компании реализуют это, правда? Paradox и другие ребята выполняют свою реализацию.

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

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

Майк Блазген

: Итак, появился отчет. Насколько я помню, в нем содержалось одобрение RSS.

Джим Грей

: В особенности компонента индексации. [смеется]

Майк Блазген

: Я думаю, что им особенно понравились блокировки; я думаю, что им понравилось использование Compare-And-Swap-Double. [смеется] И там содержалась некоторая неопределенная рекомендация, я не знаю, оказала ли она какое-нибудь влияние, но насколько мне известно, Злуф так никогда и не взял RSS. Петер де Джонг перешел в MIT и до сих пор там работает.



Бред Вейд

: А Мойше; где теперь Мойше?

К. Мохан

: В HP Labs. Он основал собственную компанию, которая не получилась, потом нанялся в Ashton-Tate; а теперь работает в HP Labs.

Джим Грей

: А Петер в Apollo делает транзакции в CORBA; в HP Apollo.

Майк Блазген

: С Мойше Злуфом произошло то, что он занялся некоторой вещью под названием Office by Example. На самом деле после того доклада, который я делал про SQL/DS, высупал Мойше с сообщением про Office by Example - OBE. Он получил целую группу из примерно двадцати пяти молодых настоящих программистов - не проектировщиков, он действительно заботился о том, чтобы нанять программистов. Так что у него была куча людей, и он добился того, чтобы ему дали собственное здание - Bernen House в Йорктауне, обустроился там и принялся за разработку продукта для PC. Гомори это полностью поддерживал. А потом в один из дней сменилось руководство - я думаю, что это было связано с уходом Бэнбаума (Birnbaum) и возвращением Херба Шора (Herb Schorr), а затем, возможно, Абе Пеледа (Abe Peled). И в какой-то момент эти люди напали на Мойше и сказали: "Мы не собираемся поддерживать эту работу на том уровне, на котором она поддерживается", а этот уровень составлял по сто тысяч на каждого из тридцати человек - три миллиона долларов в год. И Мойше это не понравилось, и он в конце концов ушел из IBM. Он образовал собственную компанию, которая так и не заработала, перешел в Ashton-Tate; потом компания Ashton-Tate была куплена компанией Borland, и он ушел в HP.

К. Мохан

: Теперь он делает Rendering by Example - простое для использованию средство программирования по примеру. Так что, возможно, он возвращается к чему-то типа системы автоматизации бизнеса.

Перерыв

---

---