исторически, что сделало реляционные базы данных популярными?

Question

РЕДАКТИРОВАТЬ Я только начал читать знаменитую статью Кодда 1970 года, с которой все началось, на которой был основан Oracle ( Реляционная модель данных для больших общих банков данных [pdf] ), и был поражен, обнаружив, что, похоже, он ответит на этот ТАК вопрос. В нем говорится о базах данных на рынке в то время («иерархические» и «сетевые» - как NoSQL?), Необходимости независимости от внутреннего представления и четком объяснении того, как применять математические «отношения» в базу данных.

---

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

Сегодня существует множество причин для использования RDB: это стандарт, продукты являются зрелыми, отлаженными, полнофункциональными, есть выбор поставщиков, есть поддержка, есть обученная рабочая сила и так далее. Но почему он стал таким популярным?

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

Может быть ACID транзакции (атомарность и т. Д.)? Но это не похоже на RDB.

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

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

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

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

Большое спасибо, если вы можете пролить немного света - мне давно было интересно об этом.

Answer 1

По той же причине, почему языки сценариев популярны.

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

Это не самая быстрая модель, не самая надежная модель - это просто самая производительная модель. Вы можете написать в десять раз больше запросов за час.

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

• Что такое реляционная база данных?

Answer 2

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

Чтобы быть точным, нужно сказать, что именно модель SQL, а не реляционная, в конечном итоге оказалась более успешной в коммерческом отношении. SQL далек от подлинно реляционной модели данных или языка, даже если бы он не появился без идей Кодда, чтобы вдохновить его. Создатель реляционной модели, естественно, был разочарован тем, что SQL, а не реляционный стандарт, стал стандартом базы данных. Спустя четыре десятилетия я думаю, у нас есть много причин сожалеть о том, что реляционная модель Кодда не лучше поддерживается программным обеспечением СУБД.

Answer 3

Я полагаю, что ни один из ответов на самом деле не прибил его, так как вас интересует его исторический аспект.

Если бы я выделил причину, я бы сказал, что Quassnoi был близок, но SQL был не просто языком - он имел одну замечательную особенность, которая не была распространена в 70-е годы:

• это декларативный , он описывает, что вы хотите получить и не прописывает, как это сделать

Не думаю, что это можно переоценить.

Конечно, реляционная модель также является большим фактором (и связана с вышеупомянутым)

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

примечание: по некоторым из вышеперечисленных намерений SQL и R'DBMS не полностью доставили (и / или другие модели каким-то образом преодолели свои проблемы), но это были первоначальные намерения и с учетом того, насколько стабильным был SQL в прошлом ~ 40 лет (вот ссылка на статью IBM от 1974 ) или около того она тоже не сделала такую ​​плохую, плохую работу.

Здесь также есть цитата из здесь

«Основная идея Теда заключалась в том, что отношения между элементами данных должны основываться на значениях элемента, а не по отдельно указанному связывание или вложение. Это понятие значительно упростил спецификацию запросов и допускается беспрецедентный гибкость в использовании существующих данных устанавливает по-новому », сказал Дон Чемберлин, один из изобретателей SQL, стандартный язык для запрашивая реляционные базы данных, и научный сотрудник в Almaden. "Он Считается, что пользователи компьютеров должны быть способен работать на более естественно-языковой уровень и не будет обеспокоены деталями того, где или как данные были сохранены. "

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

«У Кодда было довольно много сложные вопросы », - сказал Чемберлин. «И так как я изучал CODASYL (язык, используемый для запроса навигационные базы), я мог представьте, как эти запросы будут иметь был представлен в CODASYL программы длиной пять страниц что бы пройти через это лабиринт указателей и прочее. Codd вроде бы записать их как однострочечники. ... (T) эй не было сложно вообще. Я сказал: «Ух ты!» Это было своего рода преобразование опыт для меня. Я поняла что реляционная вещь была о после что.»

Кажется, я помню расшифровку интересного интервью о попрошайничестве SQL, но не могу его отследить ..

Answer 4

Насколько мне известно, это теория нормализации (хорошо известная третья нормальная форма Кодда) для определения реляционной модели данных, которую легко и эффективно хранить и извлекать. Затем следует стандартный язык запросов (SQL), который позволяет использовать его во всей реляционной системе БД. В то время определенно не хватало стандартизации, что также делает это привлекательным для многих.

Answer 5

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