Воссоединение SQL в 1995 г. люди, проекты, политика
Активные базы данных
В стандарте 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)
Триггеры могут использоваться для многих целей, не только для журнализации. Например, можно написать триггеры для балансировки бюджета путем сокращения капиталовложений при найме новых служащих … и возбуждения исключительной ситуации, если денежных средств для этого недостаточно.
Я собираюсь нанести небольшой удар
Джон Науман: Я собираюсь нанести небольшой удар по 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, а также структура самих документов стандарта полностью пересмотрена в соответствии со стремлением добиться более эффективной работы в области стандартизации в будущем.
Мортон Астрахан
Дон Чемберлин: Мортон был действительно необычным человеком. Я впервые встретился с Мортоном, когда перебрался в Калифорнию вместе с Реем Бойсом, Фрэнком Кингом, Верой Ватсон и некоторыми другими людьми в 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 - простое для использованию средство программирования по примеру. Так что, возможно, он возвращается к чему-то типа системы автоматизации бизнеса.
Перерыв
Планы и будущее
SQL:1999 - это еще не стандарт, хотя находится на пути к этому. В прошлом году было проведено голосования по поводу Final Committee Draft (FCD), содержащего четыре части спецификаций SQL (см. [1], [2], [4] и [5]). В ноябре 1998 г. состоялось заключительное редакторское собрание по поводу этих частей. Изменения спецификаций были представлены редактором (Джимом Мелтоном) и теперь рассматриваются участниками редакторского собрания. После завершения этого рассмотрения эти четыре части будут представлены для окончательного голосования (называемого голосованием по поводу Final Draft International Standard, или FDIS), результатом которого будет либо "одобрить и опубликовать без изменений", либо "не обобрять и вернуться к статусу FCD". В настоящее время все участники ожидают, что результатом будет "одобрить и опубликовать", что приведет к появлению пересмотренного стандарта где-то в середине 1999 г.Другая часть SQL -- SQL/CLI (см. [3]) -- также пересматривается и только что подверглась голосованию как FCD. Ожидается, что она будет опубликована позже в 1999 г. как пересмотренный вариант стандарта CLI-95.
Трудно знать, что принесет будущее, но группы и в ANSI, и в ISO договорились избегать затяжных процессов типа того, который привел к SQL:1999. Мы все уверены, что шесть лет - это просто слишком много, особенно, если учитывать тот факт, что весь мир работает все больше и больше "во времени Web". Разрабатываются планы, в соответствии с которыми пересмотренные варианты стандарта должны появляться примерно через каждые три года, даже если технические усовершенствования будут более скромными, чем в SQL:1999.
В дополнение к развитию основных частей стандарта SQL разрабатываются дополнительные части стандарта, посвященные таким вопросам, как темпоральные базы данных, связь с языком Java (эти вопросы разъяснялись в предыдущем выпуске SIGMOD Record) и управление внешними данными наряду с данными SQL.
Первое издание этого документа было
Первое издание этого документа было опубликовано в World Wide Web. В надежде облегчить его поиск и обеспечить возможность ссылок я повторно выпустил документ в виде SRC Technical Note.В первое издание я включил ряд библиографических ссылок для читателей, желающих узнать больше, чем то, что охватывают темы документа. В эту редакцию внесены некоторые коррективы и ряд добавок к этим ссылкам. Имеется несколько ссылок, которые могут представлять общий интерес для читателей документа: обзор области баз данных во время выполнения проекта System R и техническая ретроспектива System R.
Весной 1994 г. Майк Блазген
Весной 1994 г. Майк Блазген (Mike Blasgen) решил, что следует отпраздновать двадцатилетнюю годовщину проекта System R. Осенью 1994 г. Майк привлек Джима Грея (Jim Gray) к локальной подготовке и предложил:"Пригласить людей, которые работали в IBM над ранними реляционными системами. Это относится к периоду от начала 70-х до начала 80-х: десятилетие прогресса. В число приглашенных следует включить не только исходную группу System R, но и тех, кто работал в IBM над "производными" этой системы - R*, SQL/DS и DB2."
Собрание произошло в Алисомаре, Пасифик Грув (Pacific Grove), Калифорния 28-30 мая 1995 г. вслед за конференцией SIGMOD'95, которая проходила неподалеку в Сан-Хосе. Помимо встреч с давнишними друзьями, прогулок по берегу океана и магической частной вечеринки в аквариуме Монтре понедельник 29-го мая мы провели, вспоминая события двадцатилетней давности.
Я записал и расшифровал разговоры этого дня, попросил выступавших сделать уместные коррективы и выполнил окончательное редактирование. Результатом явился неформальный, но полученный из первых рук устный отчет о рождении SQL, о проекте System R , от которого произошел этот язык, а также о некоторых других реляционных системах баз данных.
Мне хотелось бы поблагодарить выступавших за просмотр документа и внесение поправок. Я также благодарен Кену Бекману (Ken Beckman), Бобу Тейлору (Bob Taylor) и Digital Equipment Corporation за помощь в осуществлении звукозаписи и представленное оборудование. Наконец, я благодарю Майка Блазгена и Джима Грея за то, что воссоединение произошло.
Пол МакДжонс
10 декабрь 1995 г.
Предыстория
Майк Блазген: Итак, теперь мы обсудим, как все это началось и как это происходило. У меня имеется временной ряд - некоторые из вас видели его, поскольку я рассылал один вариант, который поможет мне вспомнить, как приглашать людей, и также поможет вспомнить мне вещи, которые я сам помню. Так я и буду делать. Самое раннее, что я помню, это то, что я был в [Калифорнийском университете] в Беркли, и помню объявление на стене на 2-м или 4-м этаже [Кори-холла], в котором говорилось, что в Сан-Хосе происходят интересные вещи. Я был еще студентом, значит, это могло быть примерно в 1968 г. Итак, в Сан-Хосе уже велась работа над базами данных. Я не думаю, что тогда это так называлось. Это называлось управлением данными или файловыми системами - я не помню, как это называлось. Но это имело отношение к работе, которой руководил Майк Сенко (Mike Senko). И конечно, исследовательская лаборатория всегда ассоциировалась с данными, поскольку первая разработка дисковых устройств была выполнена именно там в начале пятидесятых. Так что уже в конце шестидесятых уделялось внимание программному обеспечению для управления данными. Я совсем незнаком с этим, и я не принимал никакого участия в работе до начала Фазы Ноль прототипа SEQUEL. Но в компании выполнялось много работ.
Ирв, что привело к статье Кодда (Codd), которая была опубликована в 1970 г.?
Ирв Трейджер
: Честно говоря, я не знаю. Тогда существовали два отдела, отдел систем, которым руководил Гленн Бэкон (Glenn Bacon) и другой - я думаю, что он назывался отделом информационных систем или как-то вроде этого, которым руководил Сенко, и это были совсем другие миры. Люди могли играть в пинг-понг во время ланча - тогда много играли в пинг-понг, но безо всяких технических разговоров. Вы слышали о таких вещах. В одном из отделов существовал большой проект под названием DIAM, с очень сложной структурой, сложным языком запросов. Я знаю, что там был человек по имени Тед Кодд и что существовали какие-то разногласия, но я действительно не знаю, что к чему привело. Однажды Тед Кодд неожиданно появился в отделе систем и после некоторого времени образован небольшую группу - сначала в нее входили три человека: Динес Бьернер (Dines Bjorner), Кен Декерт (Ken Deckert) и я. Мы начали работать над проектом GAMMA-0, и я взял с собой сюда статью о GAMMA-0.
Майк Блазген
: На самом деле? Она на столе артифактов?
Ирв Трейджер
: Пока нет, но будет там. GAMMA-0 замышлялась как средство самого низкого уровня, которое могло кому-нибудь пригодиться, но даже в нем присутствовало понятие поддержки разных вещей на более высоких уровнях, что потом повторилось в System R и Eagle, большом проекте в Санта-Тереза. Тем не менее, эта работа привела к появлению ключевой статьи Теда Кодда - она была опубликована в 1970 г.?
Майк Блазген
: Да.
Ирв Трейджер
: Некоторые из нас из отдела систем пытались читать ее - и не смогли разобраться ни с началом, ни с концом. [смеется] По крайней мере тогда статья казалась очень плохо написанной: какая-то промышленная мотивация, а потом прямой переход к математике. [смеется]
Боб Йост
: Я пришел туда вместе с несколькими другими людьми - я был в отделении разработки развитых систем - и я помню, что происходило около 1970 г., поскольку в это время мы работали с ребятами из IMS. Мы не поверили статье; мы думали, что пройдет не меньше десяти лет, пока что-нибудь получится. И это заняло десять лет. [смеется]
Ирв Трейджер
: Итак, у нас была эта статья; было еще несколько других статей, которые Тед написал позже; одна из них была посвящена языку DSL/Alpha, который основывался на реляционном исчислении. Гленн Бэкон, возглавлявший отдел систем, сомневался, что Тед сумеет обосновать возможность широкого использования этого языка, основанного на математическом исчислении предикатов с кванторами всеобщности и существования и переменными.
Опять же, каким-то образом, я не знаю, каким, вокруг IBM образовался ряд районов активности. Имелся проект в Научном Центре Петерли (Peterlee) в Англии. Петерли был промышленным городом. Английское правительство старалось равномерно распределить индустрию и бизнес в разных частях Соединенного Королевства, и они придумали кооперацию Петерли и IBM, говоря: "Безусловно, мы обустроим там лабораторию". Был такой человек - Терри Борден? - Терри Роджерс (Terry Rogers), который возглавил этот проект, основанный на реляционной алгебре - очень странный язык, который, как не странно, используется даже сейчас на промежуточном уровне системы. Был проект в Хесли (Hursley) (интересно, как много активности в Англии), называвшийся Прототип Хесли - это был Питер Кинг?
Раймонд Лори (Raymond Lorie):
Питер Тилман (Peter Tilman).
Ирв Трейджер:
OK, Тилман. Имелся проект в Научном Центре Кембриджа, Массачусетс. Раймонд Лори, Андрью Саймондс (Andrew Symonds) и другие принимали в нем участие. И еще был предыдущий проект, который выполнялся в Лаборатории Линкольна в MIT Полом Ровнером (Paul Rovner) (который учился в Беркли вместе с Майком, Джимом Греем, Марио [Школьником] и мною) и Джерри Фельдманом (Jerry Feldman), который позже стал профессором в Стэндфорде, а сейчас возглавляет ICSI в Беркли. Так что было имелись эти очаги, и Теду Кодду захотелось построить свой собственный очаг, что и обернулось проектом GAMMA-0.
Как-то Кодд решил организовать симпозиум в Йорктауне - как вы знаете, месте начальства исследовательского отделения, смысл был в том, чтобы отследить все активности в IBM, связанные с реляционными идеями Кодда. Мы сделали это; были представлены разные лаборатории, и каким-то образом спустя немного месяцев начался этот проект. Ему суждено было состояться в Сан-Хосе; ему суждено было получить вливание людей из Йорктауна; и мы не знали, на что это будет похоже, но это не являлось проблемой. Такие люди как Фрэнк Кинг, Дон Чемберлин и Рей Бойс, безусловно, осознавали тот факт, что представляют собой нашествие орды, но они очень чутко относились к этому и очень-очень старались привлечь людей из Сан-Хосе. Майк Сенко и его отдел были слиты с отделом систем, который переименовали в Computer Science; руководил отделом Леонард Лью (Leonard Liu). Гленн Бэкон ушел в SSD или в подразделение, которое сейчас называется SSD. Майк Сенко уехал на восток, оставаясь в IBM, и вскоре после этого умер, я думаю, во время командировки в Европу. Фрэнк Кинг держал нас несколько месяцев в режиме оперативной группы, перебирая все виды сумасшедших схем управления, таких как менторы, внутренние циклы и группы. Из этого выросла System R. Это длинная история. Я не хочу целиком захватывать эту сцену. Таковы мои смутные воспоминания о том, как все началось.
Майк Блазген
: Здорово. На самом деле, вы упомянули многие пункты моего списка: у меня числятся Майк Сенко, статья Теда Кодда, PRTV, Кембридж, ... Но откуда происходит вещь Кодда-Бахмана? Откуда взялась эта драка? Связано ли это с DBTG?
Ирв Трейджер
: Да, велась работа над этим стандартом. Она была организована Database Task Group, и все это называлось CODASYL: Common Data что-то - System Language - как это называлось? Это разновидность daja vu, потому что вы слышите сегодня, как важно следовать стандартам, и если мы так и делали, то ничего бы не сделали, потому что DBTG была богаче, чем IMS; она была сетевой, что, конечно, включает иерархию; и если бы вам были нужны плоские файлы, вы бы имели их в DBTG. Вам пришлось бы только отказаться от именованных связей. Это же здорово, правда? Вы хотите хороший язык, мы дадим вам язык. Техническое сообщество, которое тогда включало немного специалистов в области баз данных, имело свою собственную SIG, я не помню, как она называлась. SIGMOD была новой.
Раймонд Лори
: SIGFIDET.
Ирв Трейджер
: SIGFIDET. SIGMOD была своего рода источником, революционным и не воспринимаемым всерьез кружком, а SIGFIDET вела всю игру, и Бахман был мистером CODASYL. В нескольких случаях - я не помню их все, может быть, на одной из первых конференций SIGMOD, эти люди забрасывались друг на друга. Я имею в виду всего-навсего метание молний: что лучше и что хуже, что сложнее и что проще, каковы математические основы и кому это нужно.
Майк Блазген
: Один из этих дебатов был опубликован и широко распространялся.
К. Мохан (C. Mohan)
: Я думаю, дискуссия NCC. National Computer Conference.
Дон Чемберлин
: Это было на конференции SIGFIDET в Анн Арбор, Мичиган в 1974 г.
Франко Путцолу (Franco Putzolu)
: Я думаю, что некоторые люди, которые в конце концов работали на System R, работали над методами проектирования баз данных DBTG. Кроме того, как я помню, существовал проект в Йорктауне, посвященный тому, как проектировать базы данных DBTG.
Дон Чемберлин
: Я работал над этим. В 1971 г. в Йорктауне Леонард Лью привлек меня к работе над проектом операционной системы под названием System A. В те дни Леонард Лью был менеджером верхнего уровня, и я работал на Леонарда около года, пока в 1972 г. проект System A не был закрыт. Все время казалось, что имеются сдвиги, Леонард получал повышения, и вот что случилось в 1972 г. [смеется] Леонард продвинулся до должности второстепенного менеджера, а я начал работать на Фрэнка Кинга. В Йорктауне в 1972 г. мы находились в состоянии хаоса, поскольку наш проект операционной системы был закрыт, и нам было нечего делать. Леонард был довольно хитрым политиком, и он думал, что базы данных представляют достаточно важную область, чтобы ими заняться. Поэтому он реорганизовал нас в исследовательскую группу для изучения того, что нужно сделать в этой области. Я получил конкретное задание. Мне казалось, что это лакомый кусочек. Задание состояло в изучении этого предложения CODASYL DBTG. Я должен был научиться рассказывать об этом, оценить, что нужно делать со всем этим, и т.д. Итак, я стал экспертом по DBTG, мне понравилось, и я думал, что эта работа сделана хорошо. В предложении CODASYL DBTG имелись все виды сложных ссылок и ориентированные на множества правила выборки, и можно было изучать все это все дни напролет. Это была настоящая головоломка. Я относился к типу программистов; я копался во всем этом и много говорил про подобные вещи. В нашей группе был экспертом CODASYL; другие люди изучали другие вещи: CICS, IMS и прочее.
Мы знали, что где-то в провинции, в Сан-Хосе, выполняется некоторая работа. Был этот парень, Тед Кодд, у которого имелась некоторая строгая математическая нотация, но никто не относился к этому слишком серьезно. Примерно в это время был принят на работу Рей Бойс, и мы втянулись в эту игру под названием Игра с Запросами, размышляя о способах выражения сложных запросов. Но еще до начала этой игры у меня имелся опыт обращения в новую веру, и я еще помню про это. В Йорктаун приехал Тед Кодд, я думаю, на тот симпозиум, который упоминал Ирв. Он провел семинар, и многие из нас пришли его послушать. Я считаю, что для меня это было откровением, поскольку у Кодда был набор запросов, очень сложных запросов, и поскольку я занимался CODASYL, я мог представить, что для выражения этих запросов в CODASYL потребовалась бы программа в пять страниц, производящая навигацию в лабиринте ссылок и подобных вещей. Кодд мог написать их в одной строке. Это могли быть запросы типа "Найти служащих, зарабатывающих больше своих начальников". [смеется] Он вколачивал их, вы могли прочитать, обнаружить, что запросы-то совсем не сложные и сказать "Ооо". Для меня это был опытом обращения, давший мне понять значение реляционных штучек.
В это время Рей Бойс был только что принят на работу, и мы стали играть с ним в эту игру, которую мы назвали Игрой с Запросами, раздумывая над различными вопросами, которые нужно было бы выразить, и пытаясь найти соответствующий синтаксис. В эти дни возникли некоторые оригинальные идеи, которые мы собрали вместе, чтобы опробовать их и убедиться в осмысленности. Мы назвали нотацию SQUARE, что означало Specifying Queries as Relational Expressions. Мы знали, что Кодд разработал два языка, называемые реляционной алгеброй и реляционным исчислением. В реляционной алгебре основными объектами были таблицы, и вы комбинировали эти таблицы, используя операции типа соединения и проекции и подобные вещи. Реляционное исчисление было видом строгой математической нотации с кучей кванторов. Мы думали, что нам нужен язык, отличающийся от того и другого, в котором базовыми объектами были бы множества значений, и работать с этими значениями можно было бы путем отображения одного множества в другое с использованием таблиц. При наличии обычной базы данных продаж и отделов с возможностью расположения продаваемых предметов на разных этажах мы могли бы взять значение "два" и отобразить его с использованием этой нотации на отделы, находящиеся на этом этаже, а затем снова произвести отображение на предметы, продаваемые этими отделами. Мы старались показать, что эта нотация отображений проще тех сложных способов, которые позволяют выразить этот запрос в реляционном исчислении, или, существенно хуже, с использованием чего-то типа CODASYL.
Все это лежало в основе идеи SQUARE, и над этим мы Реем работали, когда перебрались в Сан-Хосе в 1973 г., вместе с Леонардом, Фрэнком, Верой Ватсон и Робином Уильямсом (Robin Williams), которые прибыли в Сан-Хосе в то же время. Джим Грей приехал на год раньше, потому что ему нравилось западное побережье. Франко и Майк, мне кажется, на следующий год, в 1974 г. Вот что происходило в Йорктауне в то самое время, когда Ирв работал с Тедом Коддом в Сан-Хосе.
Майк Блазген
: Это здорово; я узнаю вещи, которых не знал.
Ирв упоминал о том, что некоторые из нас были связаны с университетом Беркли; число этих людей поразительно велико. Вам не могло бы придти это в голову, возможно, это произошло по географическим причинам. Это Ирв, Брюс [Линдсей] (Bruce Lindsay), Пол [МакДжонс], я, Марио [Школьник], позже Боб Селинджер (Bob Selinger), Боб Йост и, конечно, Джим Грей, который, как мы говорим, был стипендиатом МакКея, не правда ли?
Джим Грей
: Как мы говорим, до полуночи.
Майк Блазген
: Его последним днем было 31 мая.
Если это кому-нибудь интересно, здесь имеется Общий Каталог университета Беркли за 1968 г. В этот год я преподавал в Беркли. Моего имени здесь нет. Присутствует имя Балтера Лампсона (Bulter Lampson), у которого был курс по операционным системам.
Брюс Линдсей
: Я слушал этот курс.
Марио Школьник
: Я слышал сплетни, что можно было завалить этот курс только по причине наличия описок в отчетах. Я очень чувствительно относился к этому, потому что только что переехал в Беркли из Чили.
Франко Путцолу
: Вы знаете, когда началась INGRES?
Майк Блазген
: Не могу сказать точно, примерно в это же время. Я поступил в Беркли в начале 1975 г. Моим руководителем в Беркли был Джин Вонг (Gene Wong). Он был одним из разработчиков. У Вонга имелась процедура оптимизации, которую он отстаивал, и эта процедура была реализована в INGRES. Стоунбрейкер (Stonebraker) разработал QUEL. QUEL был отображен на этот трюк, который я на самом деле не помню и который не является основным вкладом, внесенным в мир INGRES.
Ирв Трейджер
: Идея заключалась в оптимизации на основе того, как запрос ведет себя в динамике, так?
Майк Блазген
: Ну, это был своеобразный метод...
Раймонд Лори
: Запрос с единственной переменной.
Майк Блазген
: Да, это так, трюк с единственной переменной. Я видел это в работающем виде в 1975 г. Можно было ввести текст на QUEL и получить нечто, похожее на UFI. Они поддерживали только запросы - возможности обновлений отсутствовали. Я полагаю, что можно было иметь нескольких одновременных пользователей, это была система с разделением времени. Она работала на PDP-11/45.
Джим Грей
: Примерно в 1972 г. Стоунбрейкер получил грант для разработки системы баз данных с гео-запросами. Ее намеривались использовать для изучения городского планирования. В проекте не делался какой-либо инструмент географических баз данных; очень быстро центр тяжести переместился на построение системы реляционных баз данных. Результатом стала система INGRES. Проект стартовал где-то в 1972 г., и от него произошло много вещей: Ingres, Britton-Lee и Sybase. Между группой IBM в Сан-Хосе и группой Беркли установились враждебные отношения, поскольку они работали на очень-очень похожими вещами и имели очень-очень похожие идеи. Почти все были молодыми и неуверенными в себе (новичками), поэтому имелось сильное беспокойство за приоритет публикаций. В результате дело дошло до того, что лучшие идеи не рассказывались даже друг другу. Разговоры могли привести к появлению статей без указания имен рассказчиков. Порой люди метались в разные стороны; Ренди Кац (Randy Katz) был в обоих лагерях. Временами на лето в IBM приходили студенты, и временами мы все выступали, но всегда очень осторожно. В архиве сохранились слова Стоунбрейкера: "Балодарим за указание на то, что в параграфе таком-то статьи такой-то мы забыли сослаться на ???" Конечно, это не относилось только к одной стороне. Ребята из Беркли думали, что парни из IBM сдирают идеи из проекта INGRES. У нас были натянутые отношения.
Майк Блазген
: Лично у меня остались довольно приятные воспоминания об этих отношениях. Но я знаю многих других, таких как Фрэнк и прочие, у которых по этому поводу остались плохие воспоминания, поскольку у нас, вероятно, заимствовались идеи и использовались ими безо всякого разрешения.
Джим Грей
: И наоборот.
Франко Путцолу
: Vice versa.
Майк Блазген
: OK, и наоборот. Но я всегда слышал обвинение в адрес другой стороны. [смеется]
Но лично у меня были только хорошие отношения - ну, Джин Вонг был руководителем моих исследований и одним из ключевых игроков в этом деле. Джон Пол Джакоб (John Paul Jacob) организовал мероприятие в Католическом университете Рио в 1975 г., я думаю, летом 1975 г., но может быть, и летом 1976 г. Шарон и я отправились в Рио, это было действительно приятное путешествие с остановками в других местах Южной Америки.Там были Майк Стоунбрейкер в течение месяца, Деннис Цикридзис (Dennis Tsichridzis) из университета Торонто с женой, мы с Шарон и другие. Я не помню, кто еще из IBM были там; кто-нибудь из этой комнаты ездил? Джима не было. Я провел в Рио, возможно, три недели: одну неделю читал лекции на этой конференции, другую неделю с Шарон, просто болтаясь и снова читая лекции. Мы держались вместе впятером: Деннис с женой, мы с Шарон и Майк Стоунбрейкер (он был один). И так мы вместе и крутились. И я подружился с Майком, поскольку был приклеен к этому далекому месту, где было нечего делать, кроме как выпивать, чем мы много и занимались. Так что мы с Майком очень сблизились; я всегда думал, что он относится ко мне очень хорошо. Конечно, я не знаю, не говорил ли он что-нибудь за моей спиной.
Джим Грей
: Хорошо то, что вы работали над B-деревьями, а они не сделали B-деревья. [смеется] Я работал над блокировками, а они не сделали блокировок, поэтому я тоже был OK.
(4) E.F. Codd. "A Relational Model of Data for Large Shared Data Banks" CACM 13, 6 (June 1970 pages 377-387.
(5) M.M. Astrahan, E.B. Altman, P.L. Fehder, and M.E. Senko. "Concepts of a Data Independent Access Model" 1972 ACM SIGFIDET Workshop Report, pages 349-362.
(6) E.B. Altman, M.M. Astrahan, P.L. Fehder, and M.E. Senko. "Specifications in a Data Independent Access Model" 1972 ACM SIGFIDET Workshop Report, pages 363-376
(7) D. Bjorner, E.F. Codd, K.L. Deckert, and I.L. Traiger. The GAMMA-0 n-ary Relational Data Base Interface: Specifications of Objects and Operations. IBM Research Report RJ1200. San Jose, California (April 1973).
(8) IMS - это аббревиатура от Information Management System, первой системы управления базами данных IBM.
(9) E.F. Codd. A database sublanguage founded on the relational calculus. Proc. ACM SIGFIDET Workshop on Data Description, Access, and Control, San Diego, California (November 1971) pages 35-68.
(10) Система RM (Relational Memory) поддерживала бинарные отношения; см.:
A.J. Symonds and R.A. Lorie. "A schema for description a relational data base" Proc. ACM SIGFIDET Workshop on Data Description, Access, and Control, (November 1970) pages 201-229.
R.A. Lorie and A.J. Symonds. "A Relational Access Method for Interactive Applications." Courant Computer Science Symposia, Vol. 6: Data Base Systems. Prentice-Hall, Englewood Cliffs, New Jersey (1971).
Следующая система XRM (Extended Relational Memory) поддерживала n-арные отношения; см.: R.A. Lorie. XRM - An Extended (N-ary) Relational Memory. IBM Technical Report G320-2096. Cambridge Scientific Center, Mass. (January 1974).
(11) J.A. Feldman and P.D. Rovner. "An Algol-Based Associative Language" CACM 12, 8 (August 1969) pages 439-449
(12) International Computer Science Institute.
(13) SSD означает Storage Systems Division.
(14) PRTV означает Peterlee Relational Test Vehicle. См.:
Stephen Todd. "PRTV, an efficient implementation for large relational data bases" Proc. VLDB, Florence, Italy (1975), pages 554-556
(15) На самом деле CODASYL расшифровывается как Conference on Data Systems Languages, которая была образована в 1959 г. для проектирования языка обработки данных COBOL, ориентированного на применение в бизнесе. Входящая в состав CODASYL Data Base Task Group определила то, что стали называть моделью баз данных DBTG:
CODASYL Data Base Task Group. Report of the CODASYL Data Base Task Group. ACM (April 1971).
R.W. Taylor and R.L. Frank. "CODASYL Data-Base Management Systems" ACM Computing Surveys 8, 1 (March 1976) pages 67-103.
(16) IMS - иерархическая система.
(17) C. Bachman. "The programmer as navigator" (Turing Award lecture) CACM 16, 11 (November 1973) pages 653-658.
(18) " Data Models: Data Structure Set versus Relational" Supplement to Proc. ACM SIGMOD Workshop on Data Description, Access and Control, Ann Arbor, Michigan (May 1974).
(19) CICS обозначает Customer Information Control System, монитор обработки транзакций компании IBM, среда написания приложений оперативной обработки транзакций.
(20) M. Stonebraker, E. Wong, P. Kregs, and G. Held. "The Design and Implementation of INGRES" ACM TODS 1, 3 (September 1976) pages 189-222.
(21) Сначала компания называлась Relational Technology Inc., а затем была переименована в Ingres Corporation. Ingres была куплена компанией ASK, которую саму купила Computer Associates International, Inc.
(22) В 1988 г. премию ACM Software System Award разделили System R (Donald Chamberlin, James Gray, Raymond Lorie, Gianfranco Putzolu, Patricia Selinger and Irving Traiger) и INGRES (Gerald Held, Michael Stonebraker and Eugene Wong).
Страницы: 2
Признание вклада отдельных участников
В течение этих лет в разработке SQL:1999 принимали участие многие и многие люди. Хотя по соображениям ограниченного объема статьи мы не в состоянии упомянуть всех, кто принимал участие в работе комитета, мы считаем правильным указать, по крайней мере, имена людей, которые написали существенное число изменений к предложениям или просто писали важные предложения.Каждый из этих людей внес существенный вклад. Некоторые из них разработали основные аспекты архитектуры SQL;1999, другие концентрировались на конкретных технологиях, таких как интерфейс уровня вызовов (SQL/CLI), третьи работали над очень специальными вопросами, такими, как безопасность. Мы поздравляем всех их -- а также и тех людей, которые не упомянуты в приведенном списке -- с успешным завершением большой работы.
Процесс разработки стандартов
Двумя юридически признанными организациями, активно вовлеченными в процесс стандартизации SQL и тем самым разработки SQL:1999, являются ANSI и ISO.Более точно, международное сообщество работает через ISO/IEC JTC1 (Joint Technical Committee 1), комитет, сформированные Международной организацией по стандартизации совместно с Международной электротехнической комиссией. В сферу ответственности JTC1 входит разработка и поддержка стандартов, связанных с информационными технологиями. Внутри JTC1 недавно был образован подкомитет CS32, названный Data Management and Interchange (управление и обмен данными), чтобы принять дела в связи с несколькими стандартами, связанными с базами данных и метаданными и разработанными другими организациями (такими, как распущенным подкомитетом SC21). В свою очередь, CS32 сформировал ряд рабочих групп для реального выполнения технической работы - WG3 (языки баз данных) отвечает за стандарт SQL3, а WG4 развивает SQL/MM (SQL Multi-Media, набор стандартов, определяющих библиотеки типов с использованием объектно-ориентированных средств SQL3).
В Соединенных Штатах стандарты IT находятся в ведении аккредитованного при ANSI комитета NCITS (National Committee for Information Technology Standardization), ранее называвшегося просто "X3". Технический комитет NCITS H2 (раньше "X3H2") отвечает за несколько стандартов, связанных с управлением данными, включая SQL и SQL/MM.
Когда был разработан SQL первого поколения (SQL-86 и его незначительное развитие SQL-89), большая - а возможно, и основная -- часть работы была выполнена в США в X3H2, а остальные страны широко участвовали в работе в режиме обзоров и критики предложений ANSI. Но ко времени опубликования SQL-89 международное сообщество начало очень активно действовать в написании предложений для спецификации того, что стало SQL-92; ситуация не изменилась во время разработки SQL:1999, и мы надеемся, что не изменится и в будущем -- SQL - это действительно совместная международная работа.
Некоторых пояснений требуют неформальные названия, которые мы применяем к разным редакциям стандарта SQL. Первые версии стандарта широко известны под названиями SQL-86 (или SQL-87, поскольку версия ISO не публиковалась до начала 1987 г.), SQL-89 и SQL-92, в то время версию, разработка которой сейчас завершается, следует называть SQL:1999. Откуда это отличие? … почему не "SQL-99"? Просто потому, что мы должны начать думать о том, как будет называться следующее поколение, и "SQL-02" вполне можно спутать с "SQL2" (название проекта, в рамках которого разрабатывался SQL-92) … не принимая во внимание тот факт, что "02" на самом деле не больше "99". Другими словами, мы не хотим, чтобы название стандарта SQL страдало от проблемы 2000-го года!
Продукты IBM SQL/DS
Майк Блазген: OK, теперь в эту картину приходит System R, которая, как ты отметил, не очень-то относилась к деле, если не считать того факта, что ты думал о возможности реализации SQL над своей подсистемой. Но кое-что произошло, и неожиданно в Санта-Тереза сказали OK по поводу System R.
Франко Путцолу
: Об этом следует рассказать Бобу Джоллсу. Я действительно не знаю подоплеку этого перехода. Единственное, что я знаю, это то, что если рассматривать компоненты верхнего уровня, то имелись проблемы с выполнением плана, но я не знаю, что побудило переход к SQL и настоящей DB2.
Боб Джоллс
: Я думаю, что лучше всего рассказывать об этом с личных позиций, чтобы показать, что это значит для каждого из нас. Каждый из нас был привлечен к этому делу тем или иным образом. Я прибыл в Санта-Тереза из Нью-Йорка в 1977 г. Я не думаю, что входил в какую-нибудь Нью-Йоркскую мафию, как некоторые из вас. Я приехал для работы менеджером отдела проектирования баз данных в лаборатории Санта-Тереза. У меня имелась некоторая техническая и деловая подготовка, и я чувствовал себя достаточно комфортно, будучи в состоянии выполнять эту работу. Я немного волновался по поводу пребывания в Калифорнии. Вы знаете, все люди на восточном побережье, которых я знал, обладали всем необходимым, чтобы сказать, что им нравится жить в Калифорнии, растить детей в Калифорнии и т.д. Так что я приехал с мыслями, что Калифорния - это страна альтернативного образа жизни, и обнаружил, что в действительности это страна альтернативных моделей данных. [смеется]
У меня была эта группа, и у каждого члена группы была своя модель данных. [смеется] У нас были ребята - поклонники DBMS - это была небольшая группа. У нас были люди, влюбленные в словари данных; они думали, что если поместить информацию в словарь, то нечего беспокоиться об этих базах данных, и так все находится в словаре, верно? Затем, у нас был UDL; Франко упоминал об этом. Идея состояла в том, что реляционный подход может быть OK, если вы подаете его в обличье долго используемых продуктов, таких как PL/1, COBOL, FORTRAN, пока вы не вынуждены говорить о нем отдельно. Так я был по меньшей мере смущен разговорами с этими людьми и их аргументами.
А потом я стал учиться System R у некоторых из моих людей и встречаться с некоторыми из вас. Честно говоря, я начал использовать System R как своего рода испытательный стенд. Я спрашивал: "Как это работает в сравнении с System R?" и всегда узнавал о проблемах System R, начиная с SQL. Мы временами слишком сильно привязываем все наше сегодняшнее обсуждение к тому, что происходило с кодом. С моей точки зрения, то, что происходило с кодом, очевидно важно для тех их вас, кто писал части кода, но реальной вещью, которую мы все делали как цельная группа людей, состояла в том, чтобы сделать реляционный подход действительностью и сделать SQL действительностью, и может существовать множество разных реализаций этого. Я постоянно слышал обо всех ограничениях SQL и о проблемах, которые не решаются на основе SQL. И потом, если вы напишите вопрос и получите корректный ответ на основе синтаксиса и семантики SQL, то имеются ограничения производительности, по причине которых это никогда не будет работать, и т.д. и т.п. Осознавая это, я сказал себе и некоторым другим вовлеченным людям, что здесь помогает мой опыт программиста, потому что я понимаю следующее: "Вот так так, имеется нечто, реально работающее, работающее каждый день в различных средах. Все люди, понимающие, как это могло бы работать, составляют списки причин, почему это неправильно, по отношению к работающей системе". И я думаю, что иногда это тот путь, который мы применяем в программировании.
Я думаю, что самым большим другом System R и SQL в Санта-Тереза была система Eagle. Вы можете считать, что Eagle была ужасным пожирателем ресурсов и т.д., но тот факт, что Санта-Тереза была полностью занята тем, как полностью заменить IMS, сделать нечто, гораздо лучшее, чем IMS и сделать много того, что было в FS, повернул все орудия в нашу сторону, в то время как мы смотрели на то, что могло бы быть лучшим способом достижения наших целей и тогда называлось DS/2. Другими словами, они дали нам все, кроме MVS, и сказали: "Давайте, ребята, разберитесь, что делать с базами данных в средах VM и DOS, а мы побеспокоимся о действительно больших 'производственных' проблемах", что и определило направленность Eagle. Так что я думаю, что эта система была лучшим другом System R в течение всего процесса, и мы занимались ей в своем собственном темпе без ужасного количества помощи от Уайт Плейнс (White Plains), локального менеджмента, Пафкипси или кого-либо еще. Мы были в состоянии принять решение двинуться вперед и использовать System R как основу SQL/DS без того, чтобы это было политически некорректным решением. И если бы мы попытались тогда принять решение о замене Eagle на System R, то я не думаю, чтобы это было возможно.
Майк Блазген
: По моим воспоминаниям, продуктом среднего класса в этой области деятельности была DOS DL/1.
Боб Джойллс
: Да.
Майк Блазген
: И к счастью для нас DOS DL/1 не рассматривалась как успех. В отличие от этого, система IMS была очень успешной.
Боб Джойллс
: Правильно.
Майк Блазген
: Поэтому очень трудно нападать на IMS. Но было очень легко нападать на DOS DL/1, поскольку ее не считали хорошим продуктом. Так что, когда вы взяли на себя ответственность за последователя DOS DL/1, подобно тому, как Eagle была последователем IMS, вам не нужно было преодолевать слишком высокий барьер.
Боб Джойллс: Да, она прибыла без большого багажа.
Джим Грей: Я думаю, что в это время ADABAS сбросила время на часах IBM.
Боб Джойллс
: Да.
Джим Грей
: Европейцы сказали: "Нам нужна небольшая система баз данных". И очаровательно то, что Джим Фрейм (Jim Frame), который, я думаю, был менеджером Санта-Тереза, сделал стандартную вещь: он поставил небольшую базу данных "вне плана". В планировании работы компании IBM было понятие плановой работы (фондируемой) и внеплановой (без отдельного бюджета). Можно было вставить одни любимые проекты в план, а другие оставить вне плана. Вы знаете, что они давали больше денег на то, что хотели от вас получить. Все, чего им хотелось, вы помещали в план, а то, что хотели делать вы, оставалось вне плана, и они давали вам больше денег. Вот как игралась игра с финансированием. Эндикотт - может быть, мы опережаем историю, - но Эндикотт только что прекратил свой проект операционной системы. Они собирались сделать единообразную VM и DOS. Поэтому образовалось семьдесят зомби, блуждающих вокруг без какого-либо дела, и они сказали: "Черт возьми, есть эта штука, которую не могут сделать в Санта-Тереза; они слишком заняты: это маломасштабная база данных. Сейчас мы ничего не знаем о таких базах данных, но, может быть, мы сможем научиться, и тогда у нас будет работа". И они попросились на это дело. Это ...?
Боб Джойллс
: Да, это так, и у меня имеется личная реакция и на это. Это было очень болезненно для меня и моей небольшой группы, поскольку мы окончательно решили базироваться на System R, и мы сказали: "Эй, мы можем сделать из этого интересный, успешный продукт". И из-за этих махинаций с управлением, про которые говорил Джим, хотя в лаборатории было 1200 человек, и для этого проекта требовалось - я не знаю - тридцать человек, он был "внеплановым". Так что, да, он получил все свое от неожиданной миграции в [IBM] Эндикотт.
Вот тогда мы подошли к тому, что назвали Plan B. [смеется] Поскольку наша миссия закончилась, мы сказали: "OK, у нас больше нет этого дела. Мы будем делать часть Eagle, связанную с базами данных". Мы подошли с Plan B говоря, что если что-нибудь случайно должно происходить с оставшейся частью Eagle, то мы могли бы это делать. Если опять говорить о политической корректности и некорректности, то не было правильно сказать, что это произойдет, но было OK сказать: "Ну, если это случится, то мы могли бы это делать", и это было Планом B. Итак, я и моя группа начали работать над Планом B, который, по-существу, состоял в построении DB2. Внутри группы было много дебатов, и я думаю, что об этом может рассказать также Джон Науман, о том, сколько кода мы можем импортировать из System R, а сколько разработать сами, и как всегда имелось множество аргументов в пользу каждой точки зрения. В противоположном направлении произошли неожиданности, по крайней мере, с моей точки зрения. Я должен сказать, что сюрпризом SQL/DS было то, что эта работа ушла от меня или от нас. Сюрпризом проекта MVS было то, что он выполнялся быстрее, чем я ожидал. Другими словами, План A потерпел неудачу, не так ли? Система Eagle рухнула, и неожиданно к нам стали обращаться и говорить: "OK, и когда же вы сможете поставлять этот продукт баз данных?". [смеется] И тогда мы должны были принять какие-то быстрые и трудные решения по поводу ...
Франко Путцолу
: Когда вы поняли, что Eagle не пойдет? Я имею в виду, имеется ли такая дата, которую можно ...
Боб Джойллс
: Когда это поняли? Ну, я не знаю. Я считал весь процесс очень загадочным. Я не знаю, что вы - хорошо, полагаю, что я знаю, что вы чувствовали. Как бывший программист и менеджер по разработкам, я знал, как опрашивать группы, чтобы понять, находятся ли они на беговой дорожке. Для меня было совершенно очевидно, что эта группа никогда не была на беговой дорожке. Такой же феномен в Санта-Тереза, который ты описывал, был связан с Энди [Хеллером], который являлся чем-то вроде великого гуру во всем этом проекте. В этом случае люди не просто старались писать какие-то алгоритмы; программирование ста пятидесяти - двухсот - трехсот людей основывалось на этих собраниях типа летучек. Летучки вел Энди; на собраниях обсуждалось, как предполагается разрабатывать нечто. Энди уходил, и через три недели кто-то имел написанный модуль, не прошедший полного проектирования.
К. Мохан
: В это время он был в Ватсон (Watson)?
Боб Джойллс
: Он проводил много времени в Остине (Austin).
К. Мохан
: Нет, он работал в Йорктаун Вейтс, или где он тогда был?
Франко Путцолу
: Он был везде.
К. Мохан
: Но, может быть, у него где-нибудь был дом.
Майк Блазген
: Он жил в Нью-Йорке.
Боб Джойллс
: Да; он был всегда повсюду. Но он бывал в Санта-Тереза, скажем, один день в месяц - может быть, два дня в месяц - что-то вроде этого. Проходили все эти большие собрания и принимались все эти решения ...
Франко Путцолу
: Масса криков.
Боб Джойллс
: Да, много криков, воплей и тому подобного.
Жозефин Ченг
: Так мы узнавали, что он появился.
Боб Джойллс
: Да, если вы находились поблизости от этого крыла дома, то могли определить, что он здесь. Так что я думаю, что если бы вы спросили любого опытного, профессионального программиста, то он бы сказал вам, что это ведет в кратер вулкана. Но я думаю, что имелось так много уровней управления и, честно говоря, так много политики вокруг, - вы знаете: "Что думают в Пафкипси? Что думают в Гаррисоне?" и тому подобное, чему люди из менеджмента слепо следовали. Когда Майк просил меня придти и выступить на собрании, я говорил ему и говорил Джиму, что во всем этом процессе для меня главное то, что я наивен в политике. Я не относился к элите Пафкипси и Гаррисона, не относился к старой элите Санта-Тереза, поэтому я мог достаточно легко принять решение о том, что нам следует создать на базе System R продукт, который, по моему мнению, был бы наилучшим для компании, для ее заказчиков и т.д.
К. Мохан
: Где ты работал до прихода в STL? В какой организации IBM?
Боб Джоллс
: Пять лет я работал над очень большим внутренним приложением обработки транзакций как программист и менеджер. А потом я работал пять лет или около того в Business Planning в Харрисоне, где занимался прогнозированием продуктов и подобными вещами.
Майк Блазген
: Я расскажу о своем личном впечатлении, потому что все это весьма согласуется с моим представлением о том, что происходило. Моя работа состояла в том, чтобы организовывать продажи, завершать дело, правильно. System R со всеми своими недостатками, возьмите ее, любите ее всю; любите меня, любите мою дочь. Мы много раз встречались с Бобом, лично, не только с группой Боба, я имею в виду Боба как отдельную личность. И он посмотрел на System R и взял ее, а потом мы или он инсталлировали систему; я точно не помню, как это происходило. В любом случае, она предназначалась для DOS DL/1, этой среднемасштабной базы данных, ответственность за которую принял на себя Боб. И как-то он пришел в мой офис или позвонил мне, или что-то в этом роде, и сказал: "Хорошо, мы решили использовать System R". Я даже не думал об этом; самое большее, на что я надеялся, это еще на встречу для еще одного обсуждения. [смеется] Нас не отвергли. В то время не быть отвергнутыми было хорошо; отвечало минимальным надеждам. Но то, что произошло, было больше моих ожиданий, и он был серьезен. Я думал, что он просто не знает, что говорит, но он знал. Он действительно собирался взять System R и организовать ее поставки из Санта-Тереза как среднемасштабного продукта баз данных. Я уверен, что было много вещей, которые собирались переделать и модифицировать.
Потом возникла эта игра, о которой ты говорил - внеплановая работа, и на сцене появился Эндикотт. Очень важным было то, что Эндикотт не изменил решения. Они не сказали: "О, нашей целью является среднемасштабная база данных; давайте проведем массу исследований, чтобы понять требования рынка", поскольку для этого еще два года без прогресса. На самом деле, они сказали: "OK, мы беремся поставлять этот код. Что мы должны сделать, чтобы этот код стал пригодным для использования?" Это было наиболее притягательно в группе Эндикотта. В выполнении этого перехода нам во многом помогла группа Боба, и мы были очень основательно загружены. Мы говорили о посылке людей для проживания в Эндикотте и в результате решили, что это не является хорошей идеей. [смеется] Предложение не пользовалось спросом. Но эти ребята не изменили решения и это сэкономило два года.
Боб Йост
: Они послали двух или трех человек на шесть недель или около того, а потом вернули их обратно.
Майк Блазген
: Они взяли RSS почти без изменений; они взяли RDS почти без изменений, но они полностью ее переписали с PL/1 на PL/S.
Боб Йост
: На самом деле, у них имелись инструкции не делать ничего больше этого.
Майк Блазген
: Когда я жил в Вашингтоне, я отправился в Эндикотт помочь им разобраться с некоторыми проблемами, и я помню, что они считали, что количество ошибок не уменьшалось с той скоростью, с какой бы им хотелось, и у них имелись проблемы с производительностью, проблемы с рабочим набором и тому подобное. Почти до самого конца все весело на волоске. А потом состоялось большое объявление, которое происходило на какой-то конференции в Атланте или подобном месте, и я участвовал в этом мероприятии. В действительности, многие из тех слайдов, которые вы видели раньше, применялись в презентации, которую я делал как участник этого объявления. У меня имеется копия буклета, написанного Тедом Коддом, с названием Significance of the SQL/DS Announcement, который был опубликован в 1981 г. Так что я думаю, что когда произошел этот переход в Эндикотт, и у людей в Эндикотте не было никаких новых идей, то, что они собирались сделать, не было моделью данных на неделю, не было языком данных на неделю, и тогда дебаты закончились. И мы смогли получить преимущество от описанной Бобом ситуации, происшедшей с Eagle, вызвавшей провал Eagle. Хотелось ли бы кому-нибудь высказаться?
53 ADABAS - система баз данных компании Software AG.
54 Детали относительно эволюции System R к SQL/DS см. в
Donald D. Chamberlin, Arthur M. Gilbert, and Robert A. Yost. "A History of System R and SQL/Data System" Proc. VLDB, Cannes, France (September 1981), pages 456-464.
55 Замечание Боба Джоллса: "Ирв Трейджер, поскольку он был прикомандирован к Майку Саранда, имел возможность оценить аргументы как с позиции System R, так и с точки зрения STL. Возможно, он хотел бы добавить свои наблюдения к нашему обсуждению." Ответ Ирва Трейджера: "Это была сложная ситуация. Очевидно, что я был парнем из исследовательского отделения, прикомандированным на год к STL (что позже превратилось в два года). Поэтому все мои разговоры или дела в пользу System R или поддержка "интеллектуальной" обратной связи с исследовательским отделением, очевидно, могли повредить моей полезности для STL. Поэтому я заблаговременно принял решение провести год в качестве адвоката Саранды, помогая ему всем, чем могу, и повышая свою кредитоспособность. Я был привлечен к нескольким вещам, но самая большая работа состояла в том, чтобы помочь ему понять, как работает Eagle, насколько серьезны слабые места системы, можно ли ее улучшить и если да, то как, и т.д. Так что я работал с некоторыми из этих ребят. И в то же время я достаточно хорошо узнал Боба. У нас было много дискуссий по поводу Eagle и насчет работы в области баз данных. Саранда принял решение остановить проект Eagle, что потребовало большого мужества. После принятия этого решения STL сосредоточилась на паре трудных вопросов, в решении которых я мог помочь. Одна задача состояла в том, чтобы помочь определить, что следует спасти из части системных сервисов Eagle. И конечно, другая проблема заключалась в том, чтобы получить быстро развивающуюся работу в области баз данных. Как упоминал Боб, имелись хорошие аргументы относительно того, использовать ли RDS из System R или же так называемую LSS, которая была спроектирована в STL. Но было достаточно ясно, что на самом деле LSS требует доработок, и у них имелись обычные проблемы, возникающие при построении любой сложной системы. А RDS при всех ее погрешностях, по крайней мере, уже существовала, и со временем ее можно было улучшить. Поэтому я помогал Бобу и Майку с этой позиции."
56 E.F. Codd. "The Significance of the SQL/Data System Announcement" Computerworld (February 16, 1981).
Страницы: 6
Проект System R завершается
Майк Блазген: ... в Eagle, VSS, все эти названия, в DB2, в SQL/DS. Леонард уехал в Нью-Йорк, я переместился в Вашингтон, округ Колумбия, и вы видите, как изменялся размер штата; штат сотрудников начал сокращаться. Образовались новые проекты; мы можем поговорить о новых проектах, но это не относится к теме встречи. Фрэнк [Кинг] - это было за несколько недель до того, как он покинул нас и вернулся на восток, чтобы получить свою работу - устроил обед, чтобы отметить вклад всех участников проекта. И я помню, что я сидел у себя за столом в Вашингтоне, и зазвонил телефон; это был Фрэнк, и он сказал: "Я бы хотел, чтобы ты пришел на этот обед". И я сказал: "Ты имеешь в виду, что это супружеский долг?" Он сказал: "Да", и я сказал: "Ты имеешь в виду, что хочешь отметить наш путь?" И он сказал: "Ну да". И мы все собрались вместе, хотя я находился далеко, и у нас был обед в Ла Хасиенда (La Hacienda), между Лос-Гатосом (Los Gatos) и Сараготой (Saragota).
Дон Чемберлин
: Это происходило, когда у IBM были деньги.
Майк Блазген
: И это было очень приятное событие; оно было очень хорошо проведено. Я полагаю, что это, вероятно, была работа Бреда Вейда: каждый из нас получил памятную медаль - я думаю, что здесь сегодня имеется три и четыре таких медали - с именами людей, внесших вклад в выполнение проекта; это был символ "соединения" - возможно, соединения в стиле QBE. [смеется]
Дон Чемберлин
: Эта лента, которую мы представляли на конференции SIGMOD в 1976 г., демонстрирующая протитип Фазы Ноль, и Бред показывал ее ... и он показывал ее, переводя служащих из Эванстона в Ньюбург. Это была база данных Фазы Ноль.
К. Мохан
: Когда был этот обед? В каком году?
Дон Чемберлин
: Должно быть весной 1980 г., я полагаю.
Майк Блазген
: Немного позже времени действия тех фильмов, которые вы только что видели; на три месяца позже.
К. Мохан
: А это было в декабре 1979 г.
Майк Блазген
: Между прочим, здесь написано "Дон Розенхайм, директор лаборатории". Я наткнулся на Дона Розенхайма неделю назад в Лос-Гатосе в компьютерном магазине; он торговал. Я сказал: "Привет, Дон; сто лет не виделись". Он сказал: "Ты все еще работаешь?" [смеется] Конечно, я все еще работаю. Его слова заставили меня почувствовать себя старым. На самом деле, я пригласил его зайти, но не настаивал на этом. Я не принуждал его, говоря "Ты должен придти". Я сказал ему, что он мог бы и заглянуть.
В любом случае, это был формальный конец проекта, и многие люди переходили ко все более и более крупным вещам. Возникали новые проекты, и Пол МакДжонс покинул наш насест. Том Прайс ушел. Боб Джойллс, поняв в конце концов, что не хочет жить в Калифорнии и работать на компанию, базирующуюся в Нью-Йорке, сменил место и стал работать на Калифорнийскую компанию. Бред и Дон занялись обработкой текстов. Я не знаю, что делал Франко.
Франко Путцолу
: Я ушел в Tandem.
Майк Блазген
: Да, но в каком году? Ведь не сразу.
Франко Путцолу
: В начале 1981 г.
Майк Блазген
: OK, довольно скоро; вскоре после ухода Джима. Джим, конечно, ушел в Tandem. И немногие стойкие приверженцы остались в IBM: Ирв, я, Брюс Линдсей, Раймонд Лори и Пат Селинджер. И это был конец.
И в это время произошло много событий. На самом деле, они происходили в параллель, но в организационных целях их стоит упорядочить ... Я собираюсь попросить Пат Селинджер быть модератором оставшейся части нашей встречи.
Пат Селинджер: Хочу заметить, что Джим ушел из IBM только потому, что меня не было рядом, чтобы остановить его. В этот день я рожала. Это единственная причина, почему ты ушел.
Майк Блазген
: На самом деле, я думаю также, и я говорил это много раз. Я был менеджером Джима и когда был менеджером первого эшелона, и когда был менеджером второго эшелона, и все время, пока я выполнял эту работу, он оставался, хотя говорил, что уж больно далеко ездить. Но он оставался, потому что я ему очень нравился, и когда я ушел, он сказал "Пфффф".
Джим Грей
: Это правда; так оно и было.
(57) M.M. Zloof. "Query by Example". Proc. NCC 44 (1975) pages 431-438
(58) M.M. Zloof and S.P. de Jong. "The System for Business Automation (SBA): Programming Language" CACM 20, 6 (June 1977) pages 385-396.
(59) UFI означает User-Friendly Interface.
(60) IUP означает Installed User Program.
Джим Грей
: Разве не была выполнена повторная реализация как часть DB2?
(61) QMF означает Query Management Facility.
(62) R. Krishnamurthy and M.M. Zloof. "RBE: Rendering By Example", Proc. Eleventh International Conference on Data Endineering (March 1995), pages 288-297.
(63) Пол МакДжонс в конце 1976 г. ушел в Xerox. Том Прайс ушел в отделение офисных продуктов IBM в Остине. Боб Джойллс ушел в Tandem. Дон Чемберлин и Бред Вейд начали проект Janus.
(64) Замечание Джима: "Просто смешно. IBM сдвинулась еще дальше на юг в Скай Ренч (Sky Ranch). Тратить три часа в день на дорогу из Сан-Франциско и обратно было плохо и неправильно."
Страницы: 7
Распространение подхода
Майк Блазген: Это было в мою эру, и я помню, что люди из Санта-Тереза снова стали обсуждать возможность использования System R для чего-нибудь. Решение было положительным, система им нравилась, но они не хотели генерировать машинный код. Они хотели генерировать вместо машинного кода нечто слегка более высокого уровня; тривиального высокого уровня, вроде символического ассемблера, а затем интерпретировать его, что и сделали. И мы были против этого, да, можно понять, почему мы были против этого; я знаю, почему я был против: потому что не хотел, чтобы они что-нибудь испортили. Я думал, что было бы правильнее не делать работу заново, не распространять заново разработанную систему. У меня имеется дата, в которую они решили начать поставки VS QUERY и DB2; это было в марте 1979 г. В этом месяце была произведена первая поставка заказчику. GA, мы называли это GA.
Джим Грей
: Это была архитектура 811.
Майк Блазген
: Они добились этого на три года позже первой поставки архитектуры System R.
Джим Грей
: Но проект назывался 811 потому, что это была дата поставки: одиннадцатый месяц 1978 г. И я думаю, что [Майк] Саранга ([Mike] Saranga) и я ... Я держал пари, что они никогда ничего не начнут поставлять, и до сих пор так и расплатился за проигрыш.
Франк Путцолу
: Это была VSS?
Джим Грей
: Да, то, что превратилось в DB2. Поставка велась вместе с аппаратурой. Это была архитектура 811, так что XA было частью пакета.
Майк Блазген
: С адресом в тридцать один бит.
Джим Грей
: Было так: "FS потерпела крах; что мы будем делать? Мы вернемся на исходные позиции и сделаем новую систему баз данных для MVS. Мы поставим на 370 архитектуру XA." Адрес был длиной не в тридцать один, а всего лишь в двадцать четыре бит. Адресация была горизонтальной.
Нельзя пропустить тот факт, что Ирв был откомандирован в Пало Альто, я думаю, своевременно.
Разные
: STL.
Майк Блазген
: Нет, дважды; он командировался дважды.
Ирв Трейджер
: Леонард предложил мне и Франко отправиться в Пало Альто, где мы познакомились со Стивом Вейком (Steve Weick), Джоном Науманом (John Nauman), Бобом Джексоном (Bob Jackson) и массой других людей, участвующих в этом гигантском проекте FS. Не знаю, много ли дали эти взаимодействия. Он старался научить нас опыту реальных систем.
Франко Путцолу
: Это были странные взаимодействия. Это было частью большой попытки FS. Предполагалось, что мы будем представителями реляционного знания, реляционной мудрости. Конечно, проект FS покрывал все, что есть на свете, поэтому он должен был покрывать и реляционные базы данных. Мне было очень нелегко, потому что в то время я не обладал большим опытом в области баз данных. С другой стороны, немного поговорив с этими людьми ...
Майк Блазген
: ... ты чувствовал себя немного лучше. [смеется]
Франко Путцолу: Я отдавал себе отчет в уровне своей компетентности, но эти люди, они были экспертами ...
Майк Блазген
: Я работал на FS два или три года в Пафкипси в строении 77.
Франко Путцолу
: Я работал год на FS в Mohansic.
Майк Блазген
: Я участвовал в этом в течение двух лет. Я работал на Рича Ойлера (Rich Oehler), который работал на Пита Шнейдера (Pete Schneider), который работал на Джорджа Рейдина (George Radin), который работал на Дика Кейса (Dick Case), который работал Боб Эванс. Как вы знаете, Боб Эванс заведовал практически всеми разработками в IBM. Потому что Отделение системных разработок разрабатывало все системы. Все, кроме пишущих машинок, все, за исключением Тома [Прайса]. Я ушел из проекта FS, потому что он был слишком сложным, слишком трудным для понимания. Джим написал длинную статью и сказал "Это действительно привлекательно, но не делайте этого". Что-то вроде этого, точно не помню. Что бы это не было, не делайте этого.
Джим Мехл
: Эта штука в Пало Альто: она называлась проектом Dawn Treader?
Джон Науман
: Нет, это был другой проект; тот тоже выполнялся в Пало Альта, но был другим.
Майк Блазген
: У меня есть техническая записная книжка - нечто в картонной обложке, с проставленной на обложке датой: ноябрь 1974 г. В ней содержатся записи обо всех моих встречах в Пало Альто со всеми этими людьми, имена людей. Все эти имена утеряны. Несколько людей находятся неподалеку. Среди них Стив Вейк.
Франко Путцолу
: Да, мы с Ирвом провели там пару месяцев. Я не знаю, почему мы закончили; проект FS умер?
Ирв Трейджер
: Это было нечто вроде продвижения ползком. Мы ни с кем не имели действительно хороших контактов. Мы встречались, и они давали нам подзатыльники, улыбались и возвращались к своей работе.
Том Прайс
: Я помню, что когда FS умер, ходили слухи, что он умер за год до того, как они реально остановили проект. Это было так странно - каждый участник проекта знал, что он умер, но должен был продолжать над ним работать.
Майк Блазген
: Кстати, только что вышла книга. Насколько я знаю, у Пат есть экземпляр. Это книга Эмерсона Пафа (Emerson Pugh) Building IBM. Она начинается с Германа Холлерита. Действительно, в первой сентенции говорится о том, что произошло в 1889 г. в тот день, когда с помощью табуляторов Холлерита были выданы первые патента. А ближе к концу имеется раздел про FS, в котором говорится: "Это был самый дорогостоящий провал разработки в истории IBM". Непривычно видеть напечатанным такой текст по поводу FS. Мы все это знали, но никто никогда не хотел об этом писать. Кроме Джима, который первым сказал: "Не делайте этого".
К. Мохан
: На самом деле, автор говорит, что был обеспечен полный доступ ко всем архивам IBM без каких-либо ограничений на то, о чем можно говорить. От него не требовалось прохождение цензуры IBM до публикации рукописи.
Майк Блазген
: Как вы знаете, Паф уже не сотрудник IBM. Поэтому он написал это как независимый автор. До этого он написал три книги: Memories That Shaped an Industry, IBM's Early Computers, and IBM's 360 and Early 370 Systems, две последние являлись частью проекта IBM Technical History. Он был служащим IBM, имелись люди, которые на него работали, а у него были связи с издателями. А потом он ушел из IBM, но продолжил писать независимо и в результате получил немного большую свободу от редакторов, чем та, которую имел бы, будучи служащим.
Джим, я думаю, что наступило время ланча; что там у нас с ланчем?
Раймонд Лури
: Если говорить про компилятор, то я хотел бы поблагодарить Бреда за ужасную работу. Если вы действительно хотите что-нибудь узнать про 360 и о том, как работают базовые регистры, спросите у него; я думаю, что он еще помнит.
Франко Путцолу
: Ты помнишь это?
Майк Блазген
: Я помню одну историю о базовых регистрах Бреда и прочем. В нашем коде возникали последовательности на языке ассемблера. В такой последовательности встречался текст "Load R1, и т.д.", и это обрабатывалось некоторой программой, преобразующей последовательность в реальный машинный код. Мы выполняли проверку кода в Санта-Тереза, поскольку люди в Санта-Тереза подумывали о том, чтобы взять наш код. Они пришли и сказали, что в этом коде много ошибок, пардон, много дефектов. И в чем же были дефекты? Мы были несколько удивлены, поскольку думали, что кодируем достаточно чисто. Они сказали: "Ну, у вас есть литеральные ссылки на регистры". Другими словами, мы генерировали "Load one".
Том Прайс
: Ты не использовал EQU.
Майк Блазген
: Правильно, мы ничего не сравнивали. [смеется] Но потому, что это был back end компилятора. Я имею в виду нечто, занимающееся назначением регистров. Они были в беспорядке, они пересчитывались, вы знаете, четыре сотни ...
Бред Вейд
: В тысяче строк моего кода было обнаружено пятьсот семь дефектов. [смеется]
Майк Бзазген
: Как вы знаете, в это время имелось правило, пункт семь или что-то вроде этого. И вот Франк или кто-то из нас обратился к парню, который отвечал за качество кода, и сказал: "Мы поработаем над этим". А парень сказал: "Мы будем поставлять этот код только через мой труп". И мы поставляли его. [смеется]
К. Мохан
: Но в SQL/DS, правильно? Не DB2.
Майк Блазген
: Да, его поставлял Эндикотт (Endicott).
Франко Путцолу: Зачем они все переименовали? Насколько я помню, соглашения об именовании в RSS и RDS были достаточно либеральными. В начале имени ставилось Y или X. Ведь они все переименовали после поступления кода в Эндикотт?
Брюс Линдсей: A01, A02, A03, да, они переписали все модули RDS на PL/1 и переименовали все модули в соответствие со соглашением об именовании Эндикотта, в котором требовалось что-то вроде семи символов для имени продукта, один символ для компонента, а последний можно было использовать по своему желанию. [смеется] Помню, как я работал над кодом авторизации Бреда, написанным на PL/1 и PL/S. Время работы над версией PL/S было для меня трудным, поскольку требовалось иметь мнемонические имена - по меньшей мере три символа для мнемоники для всего, что делается - и они решили, что правильными именами являются 01, 02, 03, 04. Они действительно никогда не доходили до 10, но ...
Том Прайс
: Значит, у тебя были перекрестные ссылки между старыми и новыми именами.
Брюс Линдсей
: Да, мне пришлось сделать это. В то время соглашения IBM о кодировании представляли собой нечто.
Джим Грей
: Что у нас будет происходить дальше?
Майк Блазген
: Есть несколько вещей, которые я хочу сделать после ланча, если сейчас мы должны идти на ланч.
Джим Грей
: Мы сейчас должны идти на ланч.
Майк Блазген
: Во-первых, когда мы вернемся, Бред может включить видеозапись, и мы можем кое-что на ней посмотреть. Во-вторых, после ланча я хотел бы немного поговорить о связях между Сан-Хосе и Санта-Тереза в то критическое время, которое в конце концов привело к появлению DB2 и SQL/DS. В особенности SQL/DS, которая, хотя и была завершена в Эндикотте, на самом деле, началась в Санта-Тереза, и за которой последовала DOS DL/1, по крайней мере, по моим воспоминаниям. Менеждером всех этих проектов был Боб Джоллс, он здесь, и никто из присутствующих не может ему возразить. Я думаю, что ты можешь пополнить всю эту историю и рассказать нам, как ты добился всего, что произошло. И мы сделаем это после ланча. Это то, что происходило в начале или в течение 1982 г. и кульминацией чего в конце концов стали SQL/DS и DB2. Имеется еще кое-что для обсуждения; нам следует оставить для этого достаточное время. Нам нужно разобраться в том, почему Ларри Эллисон стал богатым, почему Джим Грей покинул IBM, почему Боб Джоллс живет в Chapel Hills и куда собирается Марио в следующем месяце. Масса интересных вещей. И это будет после того, как мы прокрутим ленты. Посмотрим на Дона Чемберлина с усами Бреда Вейда.[смеется]
Рей Бойс
Дон Чемберлин: Совместная работа с Реем была одним из величайших наслаждений, которые я получал в течение моей карьеры. Эта работа длилась не очень долгое время, но кое-что я буду помнить всегда. Рей вырос в штате Нью-Йорк на западном берегу Гудзона. Он поступил в колледж в Провиденс шт. Род Айленд. Там он встретил свою будущую жену Санди. Она была студенткой отделения по подготовке медицинских сестер. Рей получил степень доктора философии в университете Пэрдью (Purdue) в Западном Лафайете шт. Индиана, и он был одним из немногих людей из тех, которых я встречал, кому действительно нравился этот университет. После этого он стал членом группы, в которой я работал, в Йорктаун Хейтс шт. Нью-Йорк. Там мы только начмнали работу над проектами баз данных под руководством Фрэнка Кинга (Frank King).
Рей был человеком, умеющим добиваться желаемого. Он был очень умным и очень честолюбивым парнем и обладал большой энергией. На самом деле, я думаю, что если бы он был жив, то он в одном классе со Стивом Джобсом (Steve Jobs), Ларри Эллисоном (Larry Ellison) и Биллом Гейтсом (Bill Gates): каждый знал бы имя Рея, если бы он был жив сегодня. Мы с Реем работали вместе в тесном сотрудничестве в ранние дни языка SQL - в те дни он назывался SEQUEL. Наше сотрдничество было настолько тесным, что в конце дня ни один из нас не мог вспомнить, кому принадлежали идеи этого дня. Так что это было очень тесное партнерство. Основной разницей между нами было то, что Рей гораздо больше меня интересовался управлением, так что, когда пришло время выбрать менеджера для группы, Рей взялся за эту работу, и я думаю, что это было действительно хорошее разделение труда. Так что Рей некоторое время был моим боссом.
Через несколько месяцев после прибытия в Калифорнию у Рея и Санди появилась дочь Кристин. В ранние дни System R Рей и Ирв Трайдер (Irv Traider) были двумя менеджерами под руководством Фрэнка Кинга. У на с Реем был общий автомобиль. В один из дней весны 1974 г. я привез Рея на работу, а после ланча я узнал, что Рей потерял сознание во время ланча. На вид он был здоровым, крепким и энергичным , и я даже не подозревал, что у него проблемы со здоровьем. В один из дней во время ланча он вроде бы всего-навсего споткнулся, и его забрали в госпиталь. Оказалось, что у него аневризм мозга, т.е. лопнули кровеносные сосуды мозга. В медицинском центре Велли ему сделали операцию, после которой он прожил короткое время и скончался в День Отца в 1974 г. Его дочери было всего около девяти месяцев, когда он умер.
Жена и дочь Рея так и живут в Сан-Хосе, и мы поддерживаем с ними близкие отношения. Санди вернулась в школу и получила степень магистра в области клинической психологии. Сейчас она работает консультантом для родных и приемных родителей. Кристен выросла и поступила Калифорнийский университет в Санта-Барбара, где находится и сейчас - и моя дочь там же. В прошлом году она вышла замуж, в этом году закончит университет со степенью бакалавра; собирается остаться в университете и готовиться стать преподавателем.
Итак, я думаю, что наиболее важными вещами для Рея были его работа и его семья. Я думаю, что он действительно гордился бы тем, к чему привела его работа. За тот короткий промежуток времени, который был ему отпущен (меньше двух лет), он придумал нормальную форму Бойса-Кодда, по-прежнему описываемую в учебниках; он разработал язык SQL, который все еще помнят некоторые люди. Я думаю, что он гордился бы этим, как и жизнью своей семьи. Мне хотелось бы, чтобы была известна значимость работы Рея.
Реляционные свойства
Хотя мы называем эту категорию свойств "реляционными", вы быстро поймете, что их более правильно характеризовать как "свойства, связанные с традиционной ролью и моделью данных SQL" … в чем-то менее сильная фраза. Эти свойства не ограничены строго реляционной моделью, но также не связаны с объектной ориентацией.Часто эти свойства разбиваются примерно на пять групп: новые типы данных, новые предикаты, улучшенная семантика, дополнительная безопасность и активная база данных. Мы рассмотрим их по порядку.
При наличии приведенной исходной информации
При наличии приведенной исходной информации самое время дать обзор реального содержания SQL:1999. Хотя мы понимаем, что большинство читателей этого раздела не знает точного содержания даже SQL-92, ограничения на объем статьи не позволяют нам представить полный набор свойств SQL:1999. Поэтому мы собираемся ограничить свой обзор теми свойствами, которые являются новыми в этом самом современном поколении стандарта SQL.Свойства SQL:1999 можно грубо разделить на "реляционные" и "объектно-ориентированные". Для удобства мы опишем их в такой последовательности.
Структурные определяемые пользователями типы
Наиболее фундаментальным средством SQL:1999, поддерживающим объектную ориентацию, являются структурные определяемые пользователями типы; слово "структурный" отличает это средство от индивидуальных типов (которые тоже являются "определяемыми пользователями" типами, но в SQL:1999 могут базироваться только на встроенных типах SQL и поэтому не могут иметь ассоциированных с ними структур).Структурные типы имеют ряд характеристик, наиболее важными из которых являются следующие:
Посмотрим на пример определения структурного типа:
CREATE TYPE emp_type UNDER person_type AS ( EMP_ID INTEGER, SALARY REAL ) INSTANIABLE NOT FINAL REF ( EMP_ID ) INSTANCE METHOD GIVE_RAISE ( ABS_OR_PCT BOOLEAN, AMOUNT REAL ) RETURNS REAL
Этот новый тип является подтипом другого структурного типа, который можно было бы использовать для определения людей вообще, включая такие общие атрибуты как имя и адрес; новые атрибуты типа emp_type включают такие вещи, которые нехарактерны для "простых пожилых людей", такие как идентификатор служащего и размер заработной платы. Мы объявляем, что этот тип немедленно пригоден для прямого использования (instantiable) и ему разрешается иметь подтипы (NOT FINAL). Дополнительно к этому мы говорим, что любая ссылка на этот тип (см. ниже обсуждение REF-типов) порождаются из значений идентификаторов служащих. Наконец, мы определяем метод (подробнее об этом ниже), который может быть применен к экземплярам этого типа (его значениям).
После интенсивного флирта с множественным наследованием (когда у подтипов допускается наличие более одного непосредственного супертипа) теперь в SQL:1999 обеспечивается модель типов, тесно соответствующая одиночному наследованию в языке Java. При определении типа разрешается указать либо, что тип является пригодным для немедленного использования (другими словами, что могут создаваться значения этого типа), либо, что тип непригоден для немедленного использования (аналогично абстрактным типам в других языках программирования). И естественно, в любом месте -- например, в столбце -- где допускается появление значения некоторого структурного типа, может появиться и значение любого из его подтипов; это обеспечивает в точности тот тип заменяемости, который свойственен объектно-ориентированным программам.
Кстати, в некоторых объектно-ориентированных языках программирования, таких, как C++, при определении типа допускается спецификация степени инкапсуляции типа: уровень инкапсуляции атрибута PUBLIC означает, что любой пользователь этого типа может иметь доступ к атрибуту, PRIVATE означает, что к атрибуту может иметь доступ только тот программный код, который реализует методы типа, и PROTECTED означает, что к атрибуту могут иметь доступ только методы типа и методы любых его подтипов. В SQL:1999 этот механизм отсутствует, хотя предпринимались попытки его определить; мы ожидаем предложений по поводу этого механизма для будущего пересмотра стандарта.
System R
Майк Блазген: Итак, мы затронули вспомогательные, периферийные предметы и теперь можем приступить к началу System R, уже представленной Доном вместе с этой оперативной группой и другими случившимися событиями, которых я не знал. Моей исходной идеей было то, что эта двадцатилетняя годовщина должна быть годовщиной некоторого конкретного события, происшедшего в один из дней. Я собирался представить в качестве такого дня тот, в который проект стал именоваться System R. К этому времени проект полностью оперился; существовала представленная здесь мною схема. Некогда была System R; все прочие названия отпали: RDS, RSS. В действительности, исторически это могло произойти другим образом: возможно, эти названия привели к имени System R. Я думаю, что это произошло в конце 1974 г., почти на Рождество. Помнит ли кто-нибудь более точную дату? Ирв, я знаю, что ты принимал в этом участие. Я помню, как вы с Фрэнком ходили по холлу, разговаривая про название.
Ирв Трейджер
: Леонард наказал, чтобы мы все искали имя для проекта. Мы только пожимали плечами: "Это неважно". Он сказал: "Важно иметь имя для целей опознания". В течении недель мы пытались подобрать имя. Одно было Rufus, имя собаки Франко.
Франко Путцолу
: Rufus было бы более хорошим названием. Оно означает Relational User Friendly Universal System.
Майк Блазген
: Это было бы более хорошим названием.
К. Мохан
: Позже у нас действительно был проект под названием Rufus. Курт Шоунс (Kurt Shoens) ...
Ирв Трейджер
: Это было действительно трудно.
Майк Блазген
: Так проект получил название приблизительно в конце 1974 г.?
Ирв Трейджер
: Не помню.
Том Прайс
: Это было в то время, когда Леонард заставил вас всех работать на Рождество? Как-то я слышал историю про то, как он не разрешил никому отсутствовать во время праздника Christmas Eve.
Дон Чемберлин
: Это было в Йорктауне; да, я помню это. [смеется] Это было в пятницу перед Рождеством, и в лаборатории была вечеринка с явствами, Санта Клаусом, музыкой и всем остальным в кафетерии, а Леонард хотел в то же время техническое собрание. Леонард ожидал многих своих людей, и им от него хорошо досталось.
Майк Блазген
: Леонард был оригинальным человеком: много огня и серы, энергии и силы и прочие такие пары слов. Я помню, как в году 1975-м мы сбежали на пляж в Пайаро Дюнс, и Леонард встал и сказал: "OK, и что плохого происходит в отделе? Что плохое делаю я?" И он заставил говорить каждого. Каждый из нас жаловался. А он записывал этот список жалоб. Он ничего не говорил. Он только записывал жалобы. И потом он сказал: "OK, замолчите" и проговорил два часа без перерыва, объясняя нам, главным образом, то, что все наши жалобы были некорректны. [смеется]
Управление на основе консенсуса: я решил; вы соглашаетесь. [смеется] Это было поразительно; он совершенно не обращал внимание на то, что он поступает таким образом. И это работало; у него это очень хорошо работало. На случай, если вы этого не знаете, теперь он является COO (Chief Operating Officer) компании Cadence. IBM - заказчик номер один этой компании. Они продают средства проектирования электроники для размещения наших схем на чипах.
Кстати, эта штука с System R заставила меня показать вот эту картинку. Я не знаю, когда она была нарисована, но это моя любимая картинка. На ней разговаривают кролик и бобер, а за ними вы можете видеть Hoover Dam. Бобер говорит кролику: "На самом деле, я ее не строил, но она основана на моей идее." [смеется] Так вот, это маленький бобер - это System R, поскольку я не думаю, что продолжает использоваться большая часть кода System R; я полагаю, что кое-что - в SQL/DS.
К. Мохан
: Действительно, кое-что используется; главным образом, RSS.
Майк Блазген
: Замечательно, компонент индексации по-прежнему жив. [смеется] Это то, что я писал, и компонент индексации по-прежнему входит в продукт SQL/DS.
К. Мохан
: И все, что связано с теневыми страницами.
Майк Блазген
: О, теневые страницы тоже там? Это штучки Раймонда Лори.
К. Мохан
: И все вещи, относящиеся к управлению записями.
Брюс Линдсей
: Пул памяти.
Брэд Вейд (Brad Wade)
: Хотелось бы знать, может ли кто-нибудь сейчас понять это.
Пат Селинджер (Pat Selinger)
: Мохан по-прежнему читает об этом лекции.
Майк Блазген
: Вам не нужно все это понимать; от вас требуются только обеспечивать оборот и доход. Это то, что нужно сегодня.
???
: Многие из нас живут этим.
Майк Блазген
: Верно. Итак ...
Брэд Вейд
: Прежде, чем мы оставим разговор о названиях, напомню, что были еще имена RDS и RSS. Конечно, Дон был менеджером RDS до того, как это стали называть RDS; Ирв был менеджером RSS до того, как это стали называть RSS. У них был общий автомобиль, и однажды они пришли и сказали: "OK, вот вам названия: Don и Irv - Data Organized Naturally (Естественно Организованные Данные)". А как расшифровывался Irv, я забыл. Что-то вроде Intermediate или Interactive Relational ...
Майк Блазген
: Intermediate Retrieval Vehicle (Промежуточное Устройство Выборки)? Как насчет этого? Звучит хорошо. Нет, существовало Peterlee Relational Test Vehicle, так что буква V уже использовалась как приемлемый термин в Реляционной терминологии. Так что придется использовать Vehicle где-нибудь еще.
Итак, как насчет того, что происходило с System R? Ирв и Дон были менеджерами проекта. Почему бы одному из вас не повести нас по истории System R?
Дон Чемберлин
: Я думаю, что для этого потребуемся мы оба. Я начну.
Это не должен быть монолог; пожалуйста, вставайте и помогайте мне. Как сказал Ирв, в течение долгого времени после прибытия Фрэнка в Калифорнию у нас было много собраний, много обсуждений и оперативных групп; мы старались организовать подход к выполнению этой работы. Что довольно интересно, Тед Кодд не принимал в этом такого участия, которого следовало ожидать. Он занялся обработкой естественных языков и написал очень большую программу на APL под названием Rendezvous,. Он действительно не слишком влезал в болты и гайки System R. Я думаю, что он, возможно, хотел сохранить дистанцию между собой и System R на тот случай, если бы мы не справились с работой. А я думаю, что он сказал бы, что мы и не справились.
Майк Блазген
: О, он говорил это много раз.
Дон Чемберлин
: В результате получилось, что мы организовались в две группы: группу верхнего уровня, которую в конце концов назвали RDS и интересы которой относились главным образом к языковым вопросам, и группа нижнего уровня под названием Research Storage System, которую больше интересовали вопросы физического управления данными. Я в основном могу рассказать о том, что происходило в дни в верхней половинке проекта и я надеюсь, что Ирв и, может быть, кто-нибудь еще - Джим - расскажут о том, что делалось в нижней половинке.
Что действительно произошло в эти ранние дни, это то, что группа Ирва начала разработку нового интерфейса управления данными с поддержкой индексов, блокировок, журнализации, мультидоступа и транзакций и подобного рода вещей. Тем временем языковые ребята хотели построить прототип своего языка и нуждались в базе, а RSS была не готова. Единственно, чем мы могли воспользоваться, - это нечто под названием XRM, разработанное Раймондом Лори в Научном центре Кембриджа. Поэтому в начальные дни мы построили прототип языка над XRM; мы назвали это Фазой Ноль. У Брэда есть замечательная лента, которую многие из вас видели вчера вечером, представляющая полный работающий прототип SEQUEL в 1976 г. В прототипе были реализованы утверждения целостности, которые только сейчас появились в продуктах, спустя двадцать лет. [смеется] И мы продемонстрировали это, по крайней мере, показали ленту на конференции SIGMOD. Это было в 1976 г.?
Брэд Вейд
: В 1976 г.
Дон Чемберлин
: Надеюсь, что сегодня мы сможем увидеть эту ленту снова. Это замечательная лента; вы сможете увидеть Брэда с усами размером в велосипедный руль. Хорошее дело.
Фрэнко Путцолу
: Дон, а у вас был заказчик в Новой Англии?
Дон Чемберлин
: Да, на самом деле, как мне кажется, это было самым высшим достижением Фазы Ноль. Это интересная история. В те дни была куча проблем с дефицитом горючего; организация OPEC только что подняла цены на нефть, бензиновые компании экономили ее, и на заправочных станциях стояли очереди. В Школе управления MIT (MIT Sloan School of Management) имелись некоторые планы в Новой Англии, где они получили грант для производства нечто под названием New England Energy Management Information System, NEMIS, и им была нужна база данных для отслеживания того, насколько полны нефтяные цистерны, и подобных вещей. Научный центр Кембриджа был довольно близко связан с San Jose Research, и они взяли это прототип Фаза Ноль и работали с ним в Школе управления над этой энергетической системой управления. Кстати, одним из студентов MIT, привлеченным к этой работе, был некто по имени Боб Селинджер. Боб, не совал ли ты свои руки в Фазу Ноль и не использовал ли ты ее немножко кое для чего? В результате Боб приехал в Сан-Хосе как летний студент, поскольку у него был опыт обращения с прототипом Фазы Ноль. Когда он приехал в Сан-Хосе, то познакомился с некой особой по имени Пат Гриффитс (Pat Griffits). Вот как Боб попал в IBM.
Так что я думаю, что высшим достижением Фазы Ноль было ... [смеется]
Пат Селинджер
: А эта энергетическая система управления когда-нибудь использовалась?
Боб Селинджер
: В ней были базы данных. Я не уверен, что они широко использовались. Реально они использовали систему как базу данных для разработки проектов. Сохранялись площадь, число окон, а надо всем этим запускались какие-то программы на Фортране. Для извлечения данных существовал мост между Фортраном и, по-моему, PL/1. Это был хороший хоккей.
Дон Чемберлин
: Итак, вот чего хотела делать языковая группа, когда мы первый раз организовались: мы начали с основы SQUARE, но мы были не слишком удовлетворены этим. Прежде всего, было невозможно вводить текст с помощью клавиатуры, поскольку в языке использовалась куча забавных символов. Поэтому мы начали с разговоров, что нужно адаптировать идеи SQUARE к подходу с применением англоязычных ключевых слов. Такой текст было легче вводить, поскольку он основывался на структурах английского языка. Мы назвали этот язык Structured English Query Language (структурированный англоязычный язык запросов) и использовали акроним SEQUEL. И мы приступили к построению прототипа SEQUEL на основе метода доступа Раймонда Лори под названием XRM.
В это время нам захотелось выяснить, годится ли этот синтаксис для чего-либо, а в нашем штате, по непонятным причинам, имелся лингвист. Ее звали Филлипс Райзнер (Phyllips Reisner), и ее любимым делом было проведение экспериментов, связанных с человеческим фактором. И она отправилась в университет Сан-Хосе (Sun Jose State University) и подрядила группу студентов для обучения их языку SEQUEL, чтобы посмотреть, смогут ли они ему научиться. Она занималась этим несколько месяцев и написала об этом статью, получив признание за свою работу в сообществе человеческого фактора,. Я не уверен, что результаты были очень убедительны; они показали, что если достаточно усердно трудиться, то можно обучить SQL студентов колледжа. [смеется] Большее число ошибок, которые они делали, реально не имели никакого отношения к синтаксису. Они делали множество ошибок - они не умели правильно писать печатными буквами и т.п.
Глядя назад, я не думаю, что проблема, которую, как нам казалось, мы решали, была настолько важной. Мы думали, что мы даем возможность взаимодействовать с базами данных непрограммистам. Мы думали, что открываем доступ к данным целому новому классу людей, которые могли бы что-то сделать, но не имели такой возможности, поскольку не умеют программировать. Это происходило до наступления эпохи графических пользовательских интерфейсов, которые, в конечном счете, произвели своего рода революцию; но мы ничего не знали об этом и думали, что мы обогащаем мир, делая данные доступными для непрограммистов. Все это выеденного яйца не стоит. Реальная проблема, над которой мы не думали - или, по крайней мере, которой не уделяли достаточного внимания, состояла в том, как встраивать языки запросов в языки программирования и как сделать язык, который служил бы средством обмена между разными системами. Именно в таких применениях язык SQL добился наибольшего успеха, а совсем не как язык конечных незапланированных пользователей. Так что проблема, которую мы решили, была совсем не той, про которую мы думали, что ее решаем.
Так или иначе, мы работали над этим языком, переделывая для этого SQUARE и подлаживая его к английскому языку, а затем мы начали добавлять к языку кучу вещей типа GROUP BY, которые совсем не были унаследованы от SQUARE. Так что нельзя сказать, что мы были очень удовлетворены SQUARE. Мы написали две статьи: одну про SEQUEL/DML и другую про SEQUEL/DDL. Мы очень тесно сотрудничали в этом. Авторами статьи про DML были Чемберлин и Бойс, авторами статьи про DDL были Бойс и Чемберлин безо всяких на то причин; мы всего лишь хотели их разделить. В тот год мы хотели поехать в Стокгольм, поскольку там проходил конгресс IFIP. У меня был билет до Стокгольма в связи с одной работой, которую я делал в Йорктауне, поэтому Рей представил статью про DDL на конгресс IFIP в Стокгольме, а статью про DML мы представили в SIGMOD. Вот первая страница статьи про SEQUEL/DML. Всего в ней 24 страницы. Мы считали, что это статьи-близнецы. Мы писали их вместе и думали, что они равнозначны. Но с ними обошлись по-разному. Статья про DDL была отклонена конгрессом IFIP; Рей не поехал в Стокгольм. Я все еще храню эту статью у себя в ящике; она никогда не была напечатана. Статью про DML приняли в SIGMOD. Несколько лет спустя мне позвонил парень по имени Ларри Эллисон (Larry Ellison), который читал эту статью; он выгодно использовал некоторые идеи этой статьи. [смеется] Последнее воплощение этих идей подлиннее 24 страниц; это стандарт ISO языка SQL, который описывался на прошлой неделе Нельсоном Маттосом (Nelson Mattos) на конференции SIGMOD. В нем теперь около 1600 страниц.
Джим Грей
: Вон там [ на столе артифактов] лежат две большие папки.
Марио Школьник
: Дон, я помню, ты рассказывал, что Ларри Эллисон позвонил и спросил про коды ошибок; какие коды ошибок будут использоваться в IBM. Ему хотелось быть совместимым.
Дон Чемберлин
: Ларри звонил. В то время его компания не называлась Oracle. Его компания два раза меняла название. Исходным названием было Software Development Laboratories. Он услышал про прототип System R и захотел добиться того, чтобы его продукт был полностью совместим с System R, вплоть до значений кодов ошибок. Он пришел и спросил Фрэнка: "Вы можете дать ваши коды ошибок этому парню Эллисону?", и Фрэнк ответил: "Нет - это конфиденциальная информация IBM".
Франко Путцолу
: Это была единственная конфиденциальная часть.
Майк Блазген
: Знаете, интересна вся история. Когда мы представили статью в TODS, один из рецензентов сказал, что мы должны включить в статью BNF языка SEQUEL, что мы и сделали; но в исходном варианте статьи этого не было. На этом включении настаивал рецензент и этого требовал редактор, и мы его вставили, хотя думали, что было ... что-то не так. Я думаю, что по соображениям человеческого здравого смысла нам не следовало этого делать; нам не следовало включать это дополнение, потому что оно было слишком детальным, облегчая желающим процесс воспроизведения. Я не уверен, что это так, но ...
Джим Грей
: А что вы туда вставили?
Майк Блазген
: BNF - синтаксис. Нет, семантика в статье содержалась; она не менялась, мы всегда ее описывали. Но детали синтаксиса ... Леонард, например, много лет спустя ощущал, что это была большая ошибка; мы никогда не должны были этого делать.
Франко Путцолу
: Еще позже я подумал, что публикация чего-либо была большой ошибкой.
Жозефин Ченг (Josephine Cheng)
: Просто нужно запатентовать материал, прежде чем его публиковать.
Майк Блазген
: Люди должны знать, что патенты были в основном запрещены. В то время патенты были запрещены компанией и Верховным судом. Патенты на программное обеспечение.
Франко Путцолу
: Я помню, что до 1979 г. мы публиковали все, что приходило в голову, независимо от того, было это реализовано или нет, или мы только мечтали об этом; а затем внезапно появился барьер.
Майк Блазген
: Да, в один прекрасный момент мы решили, что могли бы сделать на этом деньги. Ведь это был комплимент, не так ли?
В 1975 г. или около того мы подготовили большой пресс-релиз в связи с началом этого дела. И он был запрещен GPD. Они не разрешили нам публиковать пресс-релиз, вы помните об этом?
Ирв Трейджер
: Я не помню.
Майк Блазген
: У нас было работы со статьями. На самом деле, в этом участвовала Шарон. [смеется] Моя жена была юристом, и она помогала им запрещать публикацию.
Боб Йост
: Вы думаете, что могло бы получиться что-нибудь удачное, если бы IBM держало все закрытым? Я так не думаю. Я не думаю, что в этом случае получилось бы что-нибудь близкое по успеху.
Франко Путцолу
: Я думаю, что решающим является тот факт, что прототип был использован в SQL/DS и DB2, а не то, что он был популярен в университетах.
Майк Блазген
: Обычно я много говорю об этом. В течение долгого времени я был чем-то вроде штатного рассказчика про System R, и многие люди в IBM задавали мне этот вопрос. Мой ответ в точности совпадал с тем, что сказал Йост: если бы мы не опубликовали эти статьи, ничего бы не получилось. И причиной провала было бы то, что IBM проигнорировала бы эту работу.
Все
: Да.
Майк Блазген
: Нет, понятно, что если бы мы могли изменить историю и не публиковать эти статьи, и при этом знать, что появятся SQL/DS и DB2, то было бы лучше, если бы эти ранние статьи не были опубликованы. Но я убежден, что единственное, чем каждый был озабочен ... Джоллс скажет что-нибудь по этому поводу. На самом деле, в то время это было слишком рано; время должно было наступить. Но я убежден, что публикация была правильным делом. Я много знаю об этом, потому что я работал на RISC. Я был и менеджером проекта 801. По поводу этого проекта вообще ничего не публиковалось, и было гораздо труднее его раскрутить. Было гораздо труднее заставить IBM делать что-нибудь по этому поводу. Мы передали разработку компании Sun. SPARC был первым популярным RISC-процессором, и только после того, как компания Sun перешла к применению RISC, нам удалось заставить IBM проснуться.
Том Прайс
: DB2 началась только после того, как Эллисон начал делать Oracle?
Майк Блазген
: Нет, Эллисон не являлся фактором SQL/DS, а насчет DB2 я не знаю.
К. Мохан
: Нет, я говорил, что SQL/DS появилась после появления Oracle.
Майк Блазген
: О, это так, но это только показывает, сколько времени требуется IBM, чтобы что-нибудь сделать.
Ирв Трейджер
: Итак, если вернуться ко времени оперативных групп System R, которая еще так не называлась, существовало это мнение о запуске прототипа Фаза Ноль, о котором говорил Дон. Было понятно, что GAMMA-0, XRM и другие системы не обеспечивают правильную платформу. Все они обладали странной особенностью - каждая из них. Ни одна из них не хранила значения в кортеже. Они сохраняли 32-битовые штуки, которые ссылались на значения. Это было время маленьких дисков и маленькой памяти. Считалось, что если кто-либо был программистом или жил в Пафкипси (Poughkeepsie), нежелательно хранить значения "programmer" и "Poughkeepsie" больше, чем в одном экземпляре. Вы должны были иметь эти классы имен, таких как названия городов, наименования должностей и тому подобное - имена людей. Вы должны были хранить ссылки на элементы этих классов для доступа к строкам переменного размера. Все они делали именно так; все они. RAM была бинарной; идентификатор кортежа, ссылка на одно значение и ссылка на другое значение. Если этого достаточно, прекрасно, но этого оказывается достаточно очень, очень редко. Но что происходит, когда вы ищите всего-навсего один кортеж? Например, "Расскажите-ка мне про Мохана из файла Employee". Накладные расходы могут быть невероятными, поскольку нужно пройти по этому указателю и пройти по тому указателю, и почему бы не хранить все значения вместе, как это в некотором роде делалось в VSAM, IMS и DBTG.
Так что мы быстро пришли к этой реализации, а затем, опять же в режиме оперативной группы, который со временем утомляет, мы пришли к понятию промежуточного уровня, названного SLI - System Logical Interface. Он должен был обеспечить возможность выполнения запросов над множествами, но, насколько я помню, с одним индексом, одним полем и одной таблицей. SEQUEL должен был каким-то образом транслироваться в эти более мелкие штучки, и нужно было склеивать сложные запросы. Над этой идеей приступила работать моя группа, в то время как Дон, Рей, Пол Фехдер (Paul Fehder) и Мортон Астрахан работали над прототипом Фазы Ноль. Но в действительности никому из нас не нравился SLI, поэтому работа постепенно истощалась.
Происходило еще кое-что, что способствовало сворачиванию этой работы: мы вступили в заговорщические отношения с Франко. Франко был отозван из Йорктауна на основе соглашения Леонарда Лью и Гомори (Gomory) о том, кто должен переехать. Он не планировал работать над System R. Эд Альтман (Ed Altman) был одним из руководителей проекта DIAM в отделе Майка Сенко и занимал менее ответственные должности в разных других группах Computer Science. Я думаю, что Франко был вызван для того, чтобы разрабатывать с Альтманов средства физического проектирования баз данных ...
Франко Путцолу
: Да, что-то вроде этого; я никогда не выяснял.
Ирв Трейджер
: ... возможно, этим руководил пришедший из группы Сенко К.П. Ванг (C.P. Wang). Очень деликатным вопросом было то, как Леонард будет балансировать разделение мозгов между ветвями Альтмана и Фрэнка Кинга, поскольку ему не хотелось создавать впечатления, что он отбирает преимущества старой группы DIAM и покровительствует Фрэнку Кингу. Поэтому некоторые пребывающие сильные люди направлялись к Альтману, в том числе и Франко. Как-то днем Леонард сказал мне, чтобы я поговорил с Франко, я не знаю, почему он хотел, чтобы это сделал я; он был застенчивым человеком. И было ясно, что Франко весьма и весьма перспективный парень. Он знал, что делалось в области баз данных раньше, и он беспокоился о приложениях. Он читал эти непонятные небольшие статьи про ...
Франко Путцолу
: Помимо прочего, я изучал IMS; я даже однажды инсталлировал IMS в Йорктауне.
Ирв Трейджер
: Итак, мне пришло в голову, что SLI - это плохая идея и что нам нужен кто-нибудь с более практическим пониманием; я поговорил с Франко и сказал Фрэнку Кингу, что мы должны взять Франко. Но Фрэнк Кинг не хотел касаться этой ситуации по причине этого баланса сил. Каким-то образом нам удалось добиться своего.
Примерно в это время была принята на работу Кепэли Эсваран (Kapali Eswaran), которая, как помню, отчитывалась передо мной, но помогала ребятам, работающим над прототипом Фазы Ноль, в реализации ограничений целостности и триггеров, которые, как отмечалось выше, только сейчас внедрены в линию продуктов IBM. Делались и другие вещи. Мы работали над мультидоступом, стараясь обеспечить эту возможность, поскольку ни в одной из ранних систем она не поддерживалась. А если эта возможность и реализовывалась, то случайным образом. Я сделал кое-какие ранние вещи в GAMMA-0, Джим Грей был очень заинтересован, и он делал некоторые вещи, и Раймонд пришел со вспышкой этой идеи, которая стала называться предикатными блокировками. Смысл идеи был в том, что если запрашиваются множества, то почему бы и не блокировать множества: наиболее естественная вещь, какую только можно представить. И это согласовалось с тем, что мы в конце концов поняли по поводу авторизации и представлений. Вместо того, чтобы авторизовать столбцы таблицы, создайте представление этих столбцов и авторизуйте его. Кепэли услышала про эти предикатные штучки и стала работать и над предикатными блокировками, и мы также начали понимать, что транзакции подобны логическим единицам "все или ничего".
Брюс Линдсей
: В статье о предикатных блокировках, которую я нашел я ящике Джима, есть отличная строка. В небольшом параграфе говорится: "Накладные расходы и сложность конструирования предиката, проверки предиката и планирования предиката ужасают и Мортона, и Франко. Остальных это только пугает." [смеется]
Ирв Трейджер
: Был короткий период, когда мы думали, что предикатные блокировки являются правильным подходом и, хотя мы этого не говорили, можно было бы получить возможность сериального плана, который как вы знаете, представляет логический эквивалент однопользовательской системы. Но это еще не было настоящей картошкой-фри. Я помню другой день, когда я сидел в кресле Джима Грея, похожем на мешок с фасолью. У него был маленький кабинет и это громадное неудобное кресло в качестве обычного сидения. Мы говорили обо всем, что произошло. В этот день в гостях был Марк Ауслэндер (Mark Auslander). Он относился к числу блуждающих людей, любящих заглядывать вам за плечо, и вдруг Джим начал лучше понимать, что означает сериальный план, почему это важно и почему предикатные блокировки, возможно, ничем не смогут помочь. Но они помогли нам это понять. Он ссылался на статью Донована (Donovan), которому пришлось кое-что делать с сериализуемостью операций над кэшем. В статье имелись некоторые натяжки, но, насколько я помню, согласованность и сериализуемость обеспечивались. Это там было. Не прозвонил ли тогда звоночек, Джим?
Джим Грей
: Да. И еще асинхронные коммуникации Карпа & Миллера. Их интересовали вопросы детерминированности, а нас только блокировки для согласованности. Мы хотели какого-нибудь ответа, им был нужен правильный ответ.
Ирв Трейджер
: Вот что было дальше. Насколько я помню, поддержка версий... теневого механизма была очень сильной идеей в системе XRM, которую Раймонд привез нам из Кембриджа. Он перевелся достаточно близко к началу процесса. Поэтому мог ли я думать о чем нибудь еше? Восстановление, журнализация, мы хотели перейти к блокировкам на уровне записей, и мы поняли, что теневой механизм этому не противоречит и ввели запутанную комбинацию блокировок уровня записей, журнализации и теневого механизма, которая действительно работала.
Франко Путцолу
: Вроде того. [смеется]
Ирв Трейджер
: Одна из сильных идей состояла в том, что мы хотели поддерживать все модели данных, поэтому в RSS поддерживались связи, фактически, цепочки указателей, и идея состояла в том, чтобы поддерживать иерархические, сетевые и реляционные структуры данных. Со временем мы отказались от этой благородной цели, но она снова воскресла в Санта-Барбара. Это было очень интересно; мы не хотели знать, куда пойдут данные, nтремясь построить универсальную вещь низкого уровня, независимую от того, что находится на верхнем уровне.
Франко Путцолу
: Да, я бы сказал, что было два важных момента. Первое - это то, что RSS существовала. Мы воспринимаем как данность, что нужно расщепить систему на компонент низкого уровня и компонент высокого уровня. Но только в системах, происходящих от System R, имеется такое явное расщепление. Во многих системах этого нет, и я думаю, что это им вредит.
Ирв Трейджер
: Да, не было очевидно, что следует расщеплять систему и как ее расщеплять. Как я говорил, мы боролись с SLI, которая представляла собой что-то вроде среднего уровня.
Франко Путцолу
: Расщепление было сделано на правильном уровне. И другим важным моментом был упор на то, чтобы многочисленные подсистемы верхнего уровня могли использовать общее ядро нижнего уровня. Такие попытки предпринимались во всех системах, которые появились после System R, и все эти попытки провалились.
Пат Селинджер
: Я помню, Франко, что ты вел по крайней мере одно исследование по поводу того, как отобразить IMS - все конструкции: логические удаления, разреженную индексацию и все такое прочее - на уровень RSS.
Франко Путцолу
: Да, это была потеря времени. [смеется]
Джон Науман (John Nauman)
: Но ты упорно этим занимался, Франко.
Джим Грей
: Следует понимать, что все это происходило на фоне нечто, называемого FS41 - Future System, и люди в FS думали, что работа над реляционной базой данных - это немыслимая растрата исследовательской энергии. Они работали над GRID или каким-то другим проектом, который был гораздо более замысловатым и продвинутым, чем все, что делали мы - там был GUI, и был замечательным.
Джон Науман
: В действительности было три системы: предполагалась поддержка реляционных и сетевых (CODASYL) вещей, а также плоских файлов - должно было делаться все. Но эта работа была прекращена.
К. Мохан
: Но часть этого вошла в System/38, не так ли? По отношению к одним и тем же данным они допустили доступ на уровне файловой системы и с использованием высокоуровневых запросов, что до сих пор поддерживается в AS/400.
Утренний перерыв
(23) K. Shoens, A.Luniewski, P. Schwarz, J. Stamos, J. Thomas. "The Rufus System: Information Organization for Semi-Structured Data" Proc. VLDB, Dublin, Ireland (1993).
(i) Cadence Design Systems. В настоящее время Леонард Лью - президент и CEO компании Walker Interactive Systems. (Прим. переводчика.)
(ii) Hoover Dam - грандиозная плотина на реке Колорадо, построенная около 60 лет тому назад. Окрестности Hoover Dam являются национальным парком. (Прим. переводчика.)
(24) E.F. Codd. "Seven Steps to Rendezvous with the Casual User" Proc. IFIP-TC2 Conference on Data Base Management, Cargese, Corsica (April 1-5, 1974) pages 179-200.
(25) E.F. Codd, R.S. Arnold, J-M. Cadiou, C.L. Chang, N. Roussopoulos. RENDEZVOUS Version 1: An Experimental English Language Query Formulation System for Casual Users of Relational Data Bases. IBM Research Report RJ 2144, San Jose, California (January 1978)
(26) RDS означает Relational Data System.
(27) M.M. Astrahan and D.D. Chamberlin. "Implementation of a structured English query language" CACM, 18, 10 (October 1975), pages 580-588
(28) J.J. Donovan, L.M. Gutentag, S.E. Madnick, and G.N. Smith. "An Application of a Generalized Management Information System to Energy Policy and Decision Making - The User's View" Proc. NCC, AFIPS Vol. 44 (1975), pages 681-686.
(29) Теперь Пат Селинджер.
(30) P. Reisner, R.F. Boyce, and D.D. Chamberlin. "Human Factors Evaluation of Two Data Base Query Languages -- SQUARE and SEQUEL" Proceedings of the AFIPS National Computer Conference, Anaheim, CA (May 1975) page 447.
(31) P. Reisner. " Use of Psychological Experementation as an Aid to Development of a Query Language" IEEE Transactions on Software Engineering, Vol. SE-3 (May 1977) page 218.
(32) D.D. Chamberlin and R.F. Boyce. "SEQUEL: A Structured English Query Language" Proc. ACM SIGMOD Workshop on Data Description, Access and Control, Ann Arbor, Michigan (May 1974), pages 249-264. Обратите внимание статья в TODS35 содержит ссылку, в которой вместо SIGMOD указано SIGFIDET.
(33) R.F. Boyce and D.D. Chamberlin. "Using a structured English query language as a data definition language" IBM Research Report RJ1318. San Jose, California (December 1973).
(iii) Ларри Эллисон основал компанию в 1977 г. (Прим. переводчика.)
(34) Nelson Mattos. "A Overview of the Emerging Third-Generation SQL Standard" SIGMOD'95 Tutorial.
(35) M.M. Astrahan, M.W. Blasgen, D.D. Chamberlin, K.P. Eswaran, J.N. Gray, P.P. Griffiths, W.F. King, R.A. Lorie, P.R. McJones, J.W. Mehl, G.R. Putzolu, I.L. Traiger, B.W. Wade, and V. Watson. "System R: Relational Approach to Database Management" ACM TODS 1, 2 (June 1976), pages 97-137.
(36) GPD означает General Products Division, отделение, под управлением которого находится исследовательская лаборатория в Сан-Хосе.
(iv) Poughkeepsipsie Ошибка! Источник ссылки не найден. небольшой город в штате Нью-Йорк с большой историей. Неподалеку от него находится завод компании IBM по производству мейнфреймов. (Прим. переводчика.)
(v) RAM - Random Access Memory (память с произвольным доступом). (Прим. перводчика.)
(37) VSAM означает Virtual Sequential Access Method.
(38) Ральф Е. Гонори (Ralph E. Gonory) был директором IBM Research с 1970 по 1986 г.
(39) R.M. Karp and R.E. Miller. "Properties of a Model for Parallel Computation: Determinacy, Termination, and Queuing" SIAM JAM 14, 6 (June 1966), pages 1390-1411.
(40) J. Gray, P. McJones, M. Blasgen, R. Lorie, B. Lindsay, T. Price, F. Putzolu, I. Traiger. "The Recovery Manager of the System R Database Manager" ACM Computing Surveys 13, 2 (June 1981), pages 223-242.
Страницы: 3
Tandem
Джон Науман: В это время Франко работал на меня в Tandem, и я уверяю вас, что мы никуда не посылали его в качестве двойного агента. Это была действительно драматическая потеря для Tandem. Я пришел в Tandem в 1981 г. сразу после Джима. Это был интересный опыт, потому что в это время в Tandem имелись средство запросов ENFORM и файловая система ENSCRIBE, и у них в стадии производства находилось средство управления транзакциями TMF (Transaction Monitoring Facility). Мы с Джимом много работали над TMF - над подготовкой и запуском; немного - над ENSCRIBE. Кроме того, Джим писал телефонный справочник ...
Джим Грей
: TELE.
Джон Науман ... а я писал программу FULIST. Когда и пришел в Tandem, он сказал мне, что я должен внести свой вклад в области кодирования, и я потратил больше времени, чем хотелось, на изучение причудливых особенностей терминала [6520]. Когда я пришел, то надеялся заняться транзакционной системой, которую они начали делать, и превратить ее в нечто, что, как я думал, мы умеем делать, на основе того, что бы сделали в System R: преобразовать ее в DB2. Я думал, что на основе всего опыта работы с Eagle и менеджерами блокировок и восстановления мы многому научились и можем сделать все это лучше в Tandem для их архитектуры NonStop.
Джим Грей
: И мы были уверены, что IBM никогда не будет это поставлять.
Джон Науман
: Верно.
Джим Грей
: Потому что, вы знаете, организация, я имею в виду, что я не знаю, был ли к этому времени План B преобразован в План A ...
Джон Науман
: Да, был. Но ты был уверен, что система никогда не будет поставляться; как я помню, я думал, что это произойдет в течение шести месяцев. Ты был ближе к правде. Мы привлекли Франко к тому, чтобы написать базовые средства управления данными для реляционной системы баз данных, которую мы хотели построить. И в течение следующих, вероятно, трех лет мы пытались собрать группу NonStop SQL, как стали называть в конце концов завершенный продукт. Это было ужасно, поскольку имелся конкурирующий продукт. Та же история, что и FS в IBM; имелся продукт под названием Rainbow, и Rainbow была развивающейся системой. Rainbow включала все, что только ... там работал Джим, когда я присоединился. Вскоре после моего прихода Джим ушел из Rainbow, переехал и занялся реальной работой. Но проект Rainbow всегда оттягивал ресурсы от того, что мы делали, и, если посмотреть на то, что мы могли бы сделать за шесть месяцев, за пять лет, за десять лет, иногда мешал нашему продвижению. Не могу вспомнить, сколько раз Франко приходил в мой офис и внушал мне, что этот нонсенс с Rainbow следует остановить. Мы должны были стать серьезными и делать продукт. К 1983 г. мы, наконец, смогли накопить критическую массу и, как я думаю, стали добиваться действительно хорошего прогресса. Франко работал с Андреа Борр и еще несколькими людьми ...
Джим Грей
: Луиз Мадрид (Louise Madrid) пришла из Britton-Lee через Esvel.
Джон Науман
: Она пришла после ухода и возвращения Франко. Но в любом случае, достигалась критическая масса группы. Андреа отстранилась от TMF для работы над средствами базовой файловой системы, и мы действительно начали достигать существенного прогресса, и затем Франко ушел. Это было ...
Франко Путцолу
: ???
Джон Науман
: Да, но тогда я этого не знал. Это было действительно неприятно. А потом Франко вернулся, и к нам присоединился Дон [Слац], и все стало происходить гораздо лучше.
К. Мохан
: Почему он ушел?
Джон Науман
: Ему не нравился его менеджер.
Том Прайс
: Капали собирался сделать его богатым.
Джон Науман
: Я думаю, что был соблазн раскрутки работы.
Франко Путцолу
: Да, это так.
Джим Грей
: Нет, все было сложнее. Была эта презентация; я сидел в большой аудитории. Деннис МакЭвой, который теперь является главой инженерного отделения в Sybase, поднялся и рассказал о том, какой замечательной системой будет Rainbow. И прямо в середине собрания Франко встал. Он сидел в центре аудитории; он пробрался между людьми; он прошел через проход; он вышел; он ушел в Esvel и принял задание. Это его окончательно достало.
Джон Науман
: Я покинул Tandem до того, как была сделана система NonStop SQL, но она была сделана, и я слышал ото всех, что это была выдающаяся работа. На основе своего опыта работы над FS в IBM и над Rainbow я понял, что в любой компании, на которую мне приходилось работать, существует одна и та же ситуация: всегда имеется продукт следующего поколения. Всегда имеется грядущий продукт, который должен решить все проблемы, и вы должны вкладывать в него все ресурсы и фактически стопорить то, над чем происходит текущая работа. Не беспокойтесь о механизме смены поколений. Это прошлое; вы должны смотреть в будущее. Я никогда не работал в компании, где бы это сработало. Доводом всегда является то, что имеется в настоящее время - это истина также и System R - у нас была System R; это то, с чем нам следовало работать. Мы не должны были беспокоиться об изменении способа работы SYSGEN и об ее устранении, и о полностью новой аппаратной архитектуре, и о полностью новой архитектуре программного обеспечения, и об объектах, поддерживающих реляционные представления, или сетевые представления, или иерархические представления, или что-нибудь еще. Мы должны были стараться делать несколько более мелкие шаги, но в направлении гораздо более достижимой цели. Ужасно говорить это, посколько настолько привлекательно посмотреть на что-нибудь и сказать: "Мы можем изменить мир. Мы можем сделать нечто действительно важное". Но проблема в том, что лишь немногие из этих попыток удаются. Все наиболее успешные программные продукты - происходят ли они из IBM, Tandem или Microsoft - получились со второй или третьей попытки. Не с первого раза, когда это блестящий предмет, который все любят.
Майк Блазген
: На самом деле, одной из причин, по которой мы здесь собрались, является то, что System R относится к одному из немногих случаев, когда новый поход оказался подходящим.
Джон Науман
: Но не продуктом.
Майк Блазген
: Почти всегда правильно улучшать старый подход. Почти правильно было улучшать IMS. Но изредка возникает возможность сделать что-то новое, и у нас она была.
Джон Науман
: Но отличие в том, что System R не была будущим IBM - будущим IBM была FS, и будущим Tandem была Rainbow, и как только вы делаете ставку на что-то от имени всей компании, вы начинаете терять ... Я рассматриваю System R как очень хорошую идею, которая позволила добиться существенного прогресса за кулисами.
Майк Блазген
: Я понимаю разницу; ты прав.
Джон Науман
: Некоторое время я работал в 3Com, и когда я там работал, Ethernet как раз начал становиться тем, что люди воспринимали как нечто важное. Компания 3Com прошла через ряд различных направлений с этими превосходными новыми системами, которые все порождали в компании проблемы, пока не сосредоточилась на том, что составляло ее реальный бизнес. Это был Ethernet. В некотором роде, они изобрели это, а потом стали продвигать. System R представляла собой нечто, что было изобретено, а потом развивалось в очень логичной, разумной последовательности. Это не была вещь, меняющая мир за одну ночь. Я думаю, что такие попытки очень опасны. Об этом говорит мой опыт в Tandem. Франко, не хочешь ли ты рассказать о том, как была завершена работа над NonStop SQL, и как был произведен выпуск?
Франко Путцолу
: На самом деле, проект завершился достаточно успешно. Посмотрите: мы стартовали в 1984 г. и пришли к бета-версии в 1987 г.; я думаю, что это вполне приемлемо.
Джим Грей
: Могу я тебя перебить и сказать кое-что? В 1984 г. мы сказали: "По-видимому, это займет три или четыре года, и мы не рассчитываем иметь продукт до 1987 г.". И Деннис МакЕвой сказал: "Что? Я должен ждать до 1987 г., чтобы получить SQL-систему? Забудьте об этом." И поэтому мы предоставили ему план с пятьюдесятью процентами уверенности и план с девяноста процентами уверенности. По первому плану работа должна была быть завершена в 1986 г., по второму - в 1987 г. И он сказал: "Ох, OK".
Джон Науман
: Но подход Франко заключался в том, что каждый раз я шел к нему и спрашивал, как долго это будет делаться: "Франко, когда ты собираешься сделать это?" "Я сделаю это, когда сделаю."
Франко Путцолу
: Да, но от нас требовалось завершить работу в 1987 г. Мы отстали месяца на три, что не было слишком плохо, и я думаю, что это была хорошая система, по крайней мере, ее низкоуровневое ядро; возможно, я пристрастен, потому что работал над ним. Я имею в виду, что это действительно было ядро, которое масштабировалось насколько угодно, производило восстановление после сбоев в течение секунд, обладало оперативно доступными утилитами всех сортов, включало правильную реализацию блокировок - ни в одной другой системе блокировки не были реализованы правильно. [смеется] С другой стороны, конечно, имелись и некоторые минусы. Минимальная функциональность: действительно базовый, базовый SQL. Мы сделали несколько серьезных ошибок, и я ответственен за некоторые из них. Мы не очень старались приклеиться к ANSI; мы старались сделать систему интегрированной с GUARDIAN: собственное именование; собственная модель безопасности. Я думаю, что виновен в части именования, и это была серьезная, серьезная ошибка. Было приятно работать над системой. Джим, ты хочешь что-нибудь сказать по этому поводу?
Джим Грей
: Да. Вероятно, ключевой особенностью этой системы было то, что первый выпуск предназначался для OLTP; первый выпуск предназначался для обработки транзакций, и это было в 1987 г. Затем люди пошли дальше и сделали параллельный SQL, который поставлялся примерно в 1989 г., и я думаю, что Майк Понг (Mike Pong) мог бы рассказать об этом. В последние четыре или пять лет они усердно работали, чтобы сделать систему оперативной и высоко доступной. Среди средств, которые они сделали, возможность добавлять индексы на фоне изменений базы данных; реорганизация базы данных на фоне обновлений и выборок. Это интересные алгоритмы. У них не было ссылочной целостности; у них не было триггеров; у них не было внешних ключей; и т.д. Но с другой стороны, они имели много вещей, полезных для повседневных сохранения и выборки данных. Интересно посмотреть, что было потом.
Франко Путцолу
: Ядро было хорошим, и действительно интересно, что в 1989 г. у нас имелось параллелльное выполнение; три или четыре года в Tandem не делалось ничего по поводу параллельного выполнения, а потом они неожиданно обнаружили этот большой рынок DSS. Но было немного поздно; к этому времени такое открытие сделали и другие люди.
Джим Грей
: Майк Понг, ты не хочешь сказать что-нибудь о ...
Майк Понг
: Я присоединился к проекту NonStop SQL для работы над оптимизатором через несколько месяцев после начала проекта в 1984 г. Больше всего мне запомнилось то, что к моему приходу Франко завершил большую часть исполнителя. Это застряло у меня в памяти, потому что никто другой даже и не пытался осознать проект в целом! В первом выпуске мы не использовали возможности параллельной архитектуры Tandem для внутреннего распараллеливания запросов. Вскоре после начала поставок первого выпуска мы с еще одним разработчиком начали работать над внутренним распараллеливанием запросов с помощью Джима и Франко. Проектирование и реализация заняли около двух лет. Когда работа была закончена, мы были очень взволнованы, увидев на самом деле линейное масштабирование и ускорение для больших запросов. К несчастью для Tandem, продвижение этой возможности на рынке началось только два года тому назад.
Пат Селинджер
: Есть ли еще истории про Tandem? Боб Джойллс?
Боб Джойллс
: Мне нечего добавить.
Пат Селинджер
: Отлично. Теперь очередь Oracle.
(69) S. Andler, I. Ding, K. Eswaran, C. Hauser, W. Kim, J. Mehl and R. Williams. "System D: A Distributed System for Availability". Eighth International Conference on Very Large Data Bases, Mexico City (September 8-10, 1982).
(70) Замечание Джима Мехла: "Рон Ревель мог непродолжительное время заниматься исследованиями в области аппаратуры в начале System D, но он несомненно не принимал участие в работе над программным обеспечением, которое стало называться System D." Пояснение Дона: "Я вспомнил, что сначала Рон работал над процессором (и я думал, что он будет использоваться в System D). Когда в System D стали использовать Series 1, Рон переключился на работу над средствами сетевых соединений. Вскоре после того, как эта работа прекратилась, я взял Рона обратно.
(71) D. Bitton and C. Turbyfill. "Benchmarking Database Systems, a Systematic Approach", Proc. VLDB, Florence, Italy (1983).
(72) Rainbow была совершенно новой системой (архитектура, операционная система, база данных и т.д.), предназначенной для замены T16. В конечном счете, этот проект был прекращен, и был запущен проект под названием Crystal для создания маломасштабной, простой для использования системы. В свою очередь, Crystal заменила Catalyst, сильно интегрированная, транзакционная, простая для использованию клиент-серверная система (PC/T16). Около 1990 г. на базе Catalyst была образована новая компания Cooperative Solutions, основанная Деннисом МакЭвоем (Dennis McEvoy), его женой Ким Ворсенкрофт (Kim Worsencroft) (которая была лидером и вдохновителем проекта Catalyst) и еще несколькими людьми из Tandem. В конечном счете, они создали продукт с названием Ellipse, основанный на OS/2 и Sybase. Cooperative Solutions была куплена компанией Bachman Information Systems, которая теперь занимается маркетингом Ellipse.
(73) На самом деле, Ethernet был изобретен в Xerox PARC.
(74) DSS обозначает Decision-Support System.
Страницы: 9
Улучшенная безопасность
Новым средством безопасности SQL:1999 основано на понятии роли (role). Привилегии могут предоставляться ролям таким же образом, как если бы они были индивидуальными идентификаторами авторизации, и роли могут предоставляться идентификаторам авторизации и другим ролям. Эта вложенная структура может в громадной степени упростить зачастую трудную работу управления безопасностью в среде баз данных.В последние несколько лет роли реализованы во многих SQL-продуктах (хотя иногда под другими названиями); в конце концов роли попали и в стандарт.
Вера Ватсон
Майк Блазген: Спасибо, Дон.
Вера Ватсон. Я встретился с Верой, когда перебрался в Йорктаун для работы Исследовательском отделении в Нью-Йорке. Одним из членов группы была Вера Ватсон. У Веры было очень необычное происхождение. Она родилась в Китае в семье русских. Это была часть русского сообщества, занимавшего часть Китая. Если вам интересно, такое же происхождение у Юла Брайнера (Yul Brynner). Вера говорила по-русски и, добравшись в конце пятидесятых через Англию в Соединенные Штаты, была принята на работу в IBM Research по причине своего знания русского языка. В это время имелся большой оптимизм относительно автоматического языкового перевода, перевода текстов с одного языка на другой. По этому поводу существовал большой исследовательский проект. Ожидалось, что пройдет немного месяцев и все заработает. Так не получилось. Но им был нужен человек с хорошим знанием русского языка, так что Вера подошла. Со временем она вошла в состав нескольких разных групп в Йорктауне; стала программистом, участвующим в нескольких разных проектах, к участию в которых я также был привлечен (проекты в области графики и другие). Она перебралась в Калифорнию где-то в начале 1974 г. или в конце 1973 г., примерно в то же время, когда несколько других человек переехали из Нью-Йорка в Сан-Хосе. Вскоре после этого я тоже переехал с начал работать вместе с ней в одном отделе под руководством Трейджера.
У Веры имелся интерес помимо работы - альпинизм. Она была очень серьезной альпинисткой, членом Альпийского клуба в Нью-Йорке. Она была очень серьезной альпинисткой и скалолазкой. В 1975 или 1976 г. она освободилась от работы на три или четыре месяца и отправилась в Южную Америку для одиночного восхождения на Аконкагва, самую высокую гору западного полушария. Я помню, что Франсис Кинг написала стихотворение о Верином восхождении на Аконкагва. На следующий год, вероятно, это был 1977 г., у нее появилась удачная возможность присоединиться к женскому штурму Аннапурна. Аннапурна - это одна и главных вершин Гималаев. Многие из нас были вовлечены в это и сохранили в памяти начало Вериного дела. Одной из необычных вещей, которую я помню в связи с этим, состоит в том, что тогда для получения неоплачиваемого отпуска (в нашем случае на три или четыре месяца, которые требовались для штурма главного пика Гималаев) нужно было заявить IBM, что это связано с возможностью, предоставляемой один раз в жизни. Конечно, это так и было, если не учитывать того, что поход на Аконкагва тоже был возможностью, возникающей один раз в жизни. Так что у Веры были две возможности, возникающие один раз в жизни, на протяжении двух лет.
Итак, она присоединилась к группе для восхождения на Аннапурна и вошла во вторую штурмовую группу. Восхождения происходят парами, производятся парные попытки штурма вершины. Это элементы гималайского стиля с оборудованием базового лагеря. Она продвигалась к верхнему лагерю, в то время как первая штурмовая группа спускалась к предыдущему лагерю. Они прошли, и она потерялась - она и ее партнер. Мы почти уверены, что они сорвались. Они шли в связке; ?ы думаем, что одна сорвалась и утянула вторую за собой.
Я узнал об этом из телефонного звонка Джона МакКарти (John McCarthy). Вера бы замужем за Джоном МакКарти, отцом Лиспа и искусственного интеллекта. Джон позвонил мне в офис, чтобы сказать, что он только что узнал об этой беде. Помню, что я собирался на собрание отдела. Я даже помню конференц-зал в строении 28, где мы собирались. Я кратко сказал, что Вера потерялась. Они послали других постараться найти ее. Они смогли разглядеть тела на снегу внизу, но сочли опасным спускаться, и даже если бы они спустились к телам, не было возможности извлечь их без использования вертолетов и подобных вещей, а это не сочли возможным. Итак, памятник Вере установлен в базовом лагере в Аннапурна, как и других людей, погибших во время этого восхождения; Аннапурна - это серьезная гора.
Я думаю, хорошо, что мы можем вместе вспомнить о Вере. Вера многое внесла в этот проект. Если вы посмотрите на этот листок бумаги, на нем написано VM+. Этот знак плюс есть Вера. Она проделала работу по модификации операционной системы IBM, чтобы на ней можно было запустить многопользовательскую версию System R. Мы все помним Веру.
Теперь я возвращаю слово Дону для разговора о Мортоне Астрахане.
Воспоминания
Майк Блазген: Я хотел бы занять некоторое время, чтобы почтить память троих людей, которые участвовали в проекте, но не смогли быть сегодня здесь, потому что их нет в живых; троих людей, которые внесли существенный вклад на разных стадиях проекта. Эти три человека, которые не могут быть здесь, - Рей Бойс (Ray Boyce), Вера Ватсон (Vera Watson) и Мортон Астрахан (Morton Astrahan). Могу я попросить Дона Чемберлина (Don Chamberlin) сказать несколько слов о Рее Бойсе?
Воссоединение SQL в 1995 г.: люди, проекты, политика
Под редакциейПеревод: Сергей Кузнецов
Страницы: 4
Майк Блазген: Вот брошюра отдела Computer Science [IBM San Jose Research], которую мы издали в конце 1978 или начале 1979 г. В ней имеется фотография всего отдела - все люди, находящиеся в этой комнате, присутствуют на фотографии. Она была сделан в нескольких шагах отсюда, за строением 28. Эрик Карлсон (Eric Carlston), Т.К. Чен (T.C. Chen). Здесь имеется еще и список публикаций, интересно посмотреть, у кого он самый длинный. Ответ на этот вопрос, вероятно, не изменился. Вероятно, в этом году он такой же, каким был в том году. Это публикации отдела Computer Science за 1977-1978 г.г. Как вы думаете, как зовут человека, у которого больше всего публикаций?
Все
: Aстрахан [смеются]
К моему удовольствию, у Блазгена две, так что я не пустомеля. У Чемберлина имеется "Data Base System Authorization" в Foundations of Secure Computing. Вероятно, ее даже нет в его CV. Здесь имеются Чемберлин, Грей, Гриффитс, Мресс, Трейджер и Вейд. Но, конечно, правильный ответ - Рон Фейджин (Ron Fagin), у которого около десяти публикаций. Эти ребята-теоретики всегда побивают нас, ребят-системщиков. А Фрэнк Кинг написал "The phonetic encoding of word-components for the computer input of Chinese characters". Это его единственная публикация в списке. Я пущу его по кругу, и люди смогут посмотреть. В нем много хороших вещей.
Вернемся к основной теме. Несмотря на наличие некоторой оппозиции, мы планируем посвятить по крайней мере часть этой дневной сессии материалу до 1982 г. Есть ли замечания или предложения? Потому что мы не все сделали; мы не поговорили про совместные исследования; мы не упомянули взаимодействия с Санта-Тереза. И поскольку ланч начнется в полдень, у нас имеется всего 40 минут. У нас есть видеоленты, которые мы собираемся вам показать. Мы покажем вам небольшой набор слайдов до того, как идти на ланч. OK? Некоторые из вас могли видеть слайды прошлым вечером. У нас имеются видеоленты той эпохи, начиная с 1979 г., и вы можете увидеть, как выглядели тогда, если окажетесь на ленте.
Под редакцией
Перевод: Сергей Кузнецов
Страницы: 5
Под редакцией
Перевод: Сергей Кузнецов
Страницы: 6
Под редакцией
Перевод: Сергей Кузнецов
Страницы: 7
VS/QUERY (QMF)
Пат Селинджер: Итак, мы переходим к следующему пятнадцатилетию. Сейчас мы находимся где-то в середине 80-х. Мы собираемся завершить обсуждение VS/QUERY, а затем Джон Науман приступит к эпохе DB2. Боб? VS/QUERY.
Боб Джойллс
: Спасибо, Пат. После Плана B наступило время Плана A, меня попросили заняться новой работой по управлению проектами VS/QUERY и языков в Санта-Тереза. Может быть, ты не можешь быть отверженным - человеком, ответственным за внеплановую работу, и когда они решают, что ты прав, то не могут оставить тебя ответственным, это слишком затруднительно. Поэтому меня попросили заняться управлением VS/QUERY, проектом, находящимся в глубоко аварийном состоянии. VS/QUERY был продуктом, про который люди из отделения маркетинга в последние четыре или пять лет говорили: "Вы знаете, на самом деле, мы не понимаем все то, что вы делаете в Санта-Тереза, но мы хотим одну эту вещь. Дайте нам ее". И год за годом группа VS/QUERY как-то управлялась, но не была в состоянии поставить продукт. Они были в некотором роде в ловушке: встречались в Йорктауне с Мойше и другими людьми и решили, что QBE - это замечательно и что им необходимо иметь все функции QBE работающими в первом выпуске. И поскольку они знали, что язык SQL важен, им нужно было иметь SQL в своем продукте, и они хотели иметь еще и некоторые другие вещи. У них было около сорока человек и гора работы, которую нужно было сделать, а также убеждение, что все это должно быть сделано для первого выпуска. И у них всегда был повод - я думаю, опирающийся на одно и то же, о чем Пат говорила мне во время перерыва - у них имелся список проблем System R. Вы знаете, вот причина того, что мы не можем взять это готовым; в System R имеются эти проблемы и т.д. и т.п. И когда эта группа стала отчитываться передо мной, я задал вопрос типа: "Хорошо, и что же произошло, когда вы встречались с людьми из System R?" "О, мы не делали этого." Так что у них были проблемы, но они не пытались их разрешать.
Пат Селинджер: Я думаю, что одной из них было то, что при каждой ошибке диска система останавливалась и говорила "YSYSTERR".
Джим Грей
: У нас было тысяча семьсот обращений к SYSTERR. Это была большая помеха.
Пат Селинджер
: Мы сообщили Брюсу Линдсею об этой проблеме, он пришел, все пересчитал и поменял их на какой-то другой код ошибки. [смеется]
Боб Джойллс
: И они не сказали Ларри Эллисону.
Джим Грей
: Все они вызывали одну подпрограмму, называемую PANIC, и когда эта подпрограмма вызывалась ...
Боб Джойллс
: Я бы сказал, что имелось нечто вроде синдрома, который одинаково проявлялся у людей с разными моделями данных. И я надеюсь, что это не прозвучит цинично, но должен сказать, что многим людям был свойственен тот синдром, что они считали допустимым не добиваться прогресса, пока для этого имеется причина. И конечно, всегда имелась масса причин, поэтому значительный прогресс не достигался. Я бы сказал, что ребята из VS/QUERY ощущали себя пойманными в ловушку, потому что они думали, что приняли на себя обязательства за все эти вещи перед отделением маркетинга, и люди из маркетинга сказали им, что они должны иметь все эти функции QBE и т.д., а иначе они "не будут иметь продукт". В конце концов, после многочисленных обсуждений этого и собраний по поводу того, что в QBE не может транслироваться через SQL и, следовательно, какие функции из числа требуемых маркетингом будут отсутствовать, я впал в замешательство и перестал что-либо понимать. Я попросил дать мне список из десяти вещей, которые были бы недоступны в первом выпуске, поскольку их нельзя было транслировать через SQL. Потом я встретился с людьми из маркетинга и выяснил, что они не понимают, что это за вещи, а потому определенно не могут требовать их присутствия в продукте. И мы стали снижать масштабность системы до того уровня, на котором можно было получить пригодный к использованию продукт. Поскольку я ушел из IBM, то не знаю точно, как этот продукт был сделан, но, по крайней мере, когда он был выпущен, то являлся вполне успешным продуктом.
Пат Селинджер
: Это было очень прибыльное дело.
Боб Джойллс
: У них были все правильные составляющие для хорошего продукта: System R, некоторые идеи из QBE и, возможно, из других вещей ...
Роджер Миллер
: Боб, QMF - потрясающе успешный продукт. У нас была огромные затраты, поэтому мы были должны иметь высокую цену. Заказчики покупали продукт, и он стал очень выгодным.
Боб Джойллс
: Кто говорит, что ценообразование с учетом затрат не является правильным способом? Я полагаю, что с точки зрения System R мы годами испытывали с группой VS/QUERY массу переживаний и неприятностей. Я думаю, что это завершилось достаточно быстро, и они закончили проект, получив успешный продукт.
К. Мохан
: Так он отличается от QMF?
Боб Джойллс
: Нет, VS/QUERY было кодовым названием; прошу прощения: QMF.
Пат Селинжер
: И затем мы перешли к DB2.
Боб Йост
: Вы действительно запускали это на незаконнорожденной версии System R? В течение долгого времени не было DB2. Вы взяли некоторый код, заставили его работать в своей среде, получив возможность реально тестировать средства запросов.
Боб Джойллс
: Правильно. Я не помню, поставляли ли они QMF вместе с черным ящиком, содержащим старую версию System R.
Боб Йост
: Это было только для целей тестирования, поскольку в это время опорная система не существовала.
Боб Джойллс
: Итак, мы собираемся послушать, что скажет Джон про DB2? Хорошо.
Базы данных: Разработка - Управление - Excel
- Базы данных
- Разработка баз данных
- СУБД и базы данных
- Управление базами данных
- Классика баз данных
- Софт для создания базы данных
- SQL
- Access
- FoxProо
- Расширенная оптимизация подзапросов в Oracle
- Informix
- Линтер
- Postgres
- СУБД DB2
- InterBase
- Excel
- Таблицы Excel
- Справка Excel
- Программирование в Excel
- Деньги в Excel
- Задачи Excel