История создания

InterBase SQL Server был создан, разрабатывался и продавался фирмой Interbase Software Corporation (ISC). В соответствии со слухами, сотрудник DEC James Starkey, разработавший DSRI для Rdb, хотел расширить возможности Rdb, но его предложения были отвергнуты DEC. Поэтому он создал собственную компанию, разработавшую собственную RDBMS, первоначальное название которой было Groton Database System (GDS).

Во время существования ISC дистрибуцией IB (под названием StarBase) занималась фирма Cognos Inc, и до настоящего времени являющаяся одной из основных фирм, оказывающей технические консультации и сопровождение по InterBase. Впоследствие фирма ISC была приобретена компанией Ashton-Tate (в этот момент James Starkey ушел в Harbor Software), и перешла в Borland при приобретении последним Ashton-Tate.

При создании и развитии InterBase SQL Server было использовано большое количество нетрадиционных решений и новых технологий:

• UDF – определяемые пользователем функции. Расширяемость SQL-сервера не за счет увеличения количества нестандартных встроенных функций, или реализации сложного встроенного языка программирования, а при помощи внешних модулей, создаваемых на компилируемых языках 3GL (изначально C и в настоящий момент Delphi).
• Поля типа "массив" – разработаны по просьбе анонимной самолетостроительной компании (район Сиэтла). По техническому заданию компании требовалось хранить данные, получаемые единовременно с большого количества датчиков в БД, и обрабатывать эти данные по горизонтали и по вертикали. В настоящее врем этой уникальной возможностью InterBase SQl Server с успехом пользуютс самолетостроительные, исследовательские компании и финансовые биржи.
• Каскадные триггеры – позволяют разбивать на отдельные части логику обработки вставки, изменения и удаления записей. Фактически каскадные триггеры позволяют реализовать "процедурное программирование" обработки данных, допуская изменение порядка выполнения триггеров и отключение/включение триггеров "на ходу".
• Фильтры полей типа blob – пользовательские процедуры (UDF), подсоединяемые к операциям чтения и записи данных в поля blob, и позволяющие осуществлять преобразование данных "на ходу", упаковку/сжатие данных и т. д. Для каждого подтипа blob могут быть написаны свои фильтры. У термина blob есть тоже своя история. Вот что рассказывает James Starkey:

• "Барри Рабинсон, мой босс в DEC, ходил кругами и бубнил: "blobs, blobs, у нас должны быть blobs". Когда я спросил, что это такое, он ответил что именно я являюсь архитектором и сам должен знать об этом.
• Бездельничая в Колорадо Спрингс по причине снежных заносов, я не мог выехать на работу и решил заняться blob-ами. Тут то я и понял, что это должно быть такое – blob.
• Ребята, занимавшиеся Rdb/VMS объявили созданным мною blob-ам войну – во-первых, они сказали, что никогда не потеряют в продажах из-за отсутствия blob. Во-вторых, документы и графика не являются частью БД и должны хранитьс в отдельных файлах. В третьих, если даже нужно хранить документ в БД, то его надо разбить на строки и хранить именно таким образом.
• blob-ы были переименованы в "сегментированные строки", и все-таки стали частью DSRI.
• Намного позже, маркетер Apollo Терри Маккивер, влюбилась в концепцию blob, но решила что это слово должно как-то расшифровываться. В первом варианте это было "basic large objects". Но Apollo не зарезервировало за собой такую "расшифровку", и она привлекла внимание (я думаю) Informix: было объявлено, что в будущем Informix будет поддерживать "binary large objects". И началось ...
• Кто-то спросил у менеджера по продуктам DEC о том, будут ли поддерживатьс blob? Ответ был такой – "когда-нибудь в будущем". А между тем группа разработчиков уже была в курсе blob.
• Ashton Tate купила Interbase, Borland купил Ashton Tate, и расшифровываемый термин BLOb начал использоваться повсюду. Вот так."

• Сигнализаторы событий – концепция "активного сервера", уведомляющего клиентов о наступлении события. Клиент не должен ожидать события от сервера, а должен "подписаться" на уведомление. Когда событие произойдет, сервер сам уведомит подписанного на это событие клиента. Патент N 5,592,664.
• Первая коммерческая реализация двухфазного подтверждения транзакций (2PC)
• Механизм генераторов уникальных чисел – независимый от транзакций и данных в таблицах механизм, позволяющий пользователям получать гарантированно уникальные идентификаторы. См. «Генераторы и их использование».
• Множественные поколения записей – обеспечение уровней изоляции пользователей, блокировки на уровне записи, гарантия отсутствия блокировок по чтению, быстрое восстановление БД при сбоях (отсутствие лога отката), обеспечение производительности OLAP и DSS транзакций.

Craig Stunz раскопал более подробно историю многоверсионности. Со слов Анны Харрисон (Ann Harrison), жены Джима Старки (James Starkey):
 

[Jim] начал пробовать версии данных (shadowing), при помощи которых он увидел способ обеспечить режим repeatable read без блокирования updates. Затем, однажды утром в душе, он понял, что версии (shadows) также могут предотвратить конфликты обновлений и отменять работу незавершенных транзакций.

Все это происходило где-то в 1981-1984 году, а реализация многоверсионности и InterBase появились в 1985 году.

Однако, многоверсионный доступ описан в литературе в 1981 году Филиппом Бернштейном и Натаном Гудменом (Philip Bernstein and Nathan Goodman), которые впоследствии работали в Computer Corporation of America (Замечание: для чтения документов ACM требуется оплата подписки). Документ Бернштейна и Гудмена цитируют диссертацию D.P. Reed 1978 года, где достаточно четко описана MVCC, и утверждается, что это оригинальная работа. Документ Рида цитируется 66-ю авторами в The Guide to Computing Literature, и 180 раз Бернштейном и Гудменом.

Так что, идеи многоверсионности появились как минимум в виде обсуждения в документах намного раньше, чем InterBase. Однако, до реализаций так и не дошло. DEC Rdb/ELN была коммерческой СУБД, использующей MVCC, и была выпущена прямо перед InterBase, но она также разработана Джимом Старки в тот же период времени и имеет одно и то же ядро (JRD) (Rdb/VMS в свою очередь, явилась прародителем Oracle RDB). Все что существовало до этого, это некоммерческое приложение, обсуждаемое в документе Рида.

Джим Старки упоминает в комментариях, что он не был в курсе документа Рида и не обсуждал этот вопрос с Бернштейном, а пришел к этой идее независимо, но несколько позже.

Все эти технологии, объединенные с простотой установки и конфигурировани SQL-сервера, делают Borland InterBase черезвычайно мощным и удобным в работе сервером.
 

Дополнения

Комментарий James Starkey по поводу некоторых сокращений:
 

"GDML – Groton Database Manipulation Language. GDS – Groton Database Systems, первоначальное название Interbase Software Corporation (обратите внимание, что фирма начинается с "Interbase", а продукт называется "InterBase". Именно так а не иначе). GDML очень похож на встроенный язык манипулировани данными DEC Rdb/ELN, который произошел от DEC Datatrieve language, который в свою очередь произошел от America's Datalanguage фирмы Computer Corporation.GPRE – универсальный языковый препроцессор для InterBase. Он принимает на вход текст, расширенный операторами обращения к данным (embedded SQL), выдавая на выходе текст на C, C++, Pascal, PL/I, Cobol, Pascal, Ada, Ada, Ada со вставками обращений к IB API.

В общем-то GPRE – это то что получается у меня когда я пытаюсь ввести с клавиатуры слово "grep".

Groton, Ma. – это место, где располагается Reedy Meadow Research Center, где Джим, Дон, Гектор и Кассандра создали первую версию InterBase. Вскоре к ним присоединились Анна (которая жила там) и Дэйв.

Джим и Анна до сих пор вместе, Дон стал Знаменитым Ученым Мужем Промышленности, Дэйв переехал в Beacon Hill, а Гектор и Кассандра охотятся на мышей и помногу спят.

А вот Blob (тоже обратите внимание на регистр букв) не означает вообще ничего."