Исторически, что сделало реляционные базы данных популярными?
РЕДАКТИРОВАТЬ Я только что начал читать знаменитую статью Кодда 1970 года, в которой все началось, на которой был основан Oracle ( Реляционная модель данных для больших общих банков данных [pdf]), и был поражен, обнаружив, что, похоже, он ответит на этот вопрос. вопрос. В нем говорится о базах данных на рынке в то время ("иерархические" и "сетевые" - как NoSQL?), Необходимости независимости от внутреннего представления и четком объяснении того, как применять математические "отношения" к базе данных.
Исторически, какая особенность реляционных баз данных давала то преимущество, которое заставляло бизнес принимать его, делая его массовым успехом?
Сегодня есть много причин использовать RDB: это стандарт, продукты зрелые, отлаженные, полнофункциональные, есть выбор поставщиков, есть поддержка, есть обученная рабочая сила и так далее. Но почему он стал таким популярным?
Я слышал, что "иерархические базы данных" были популярны до реляционных баз данных - они звучат как хранилище значений ключей, где значение может быть другим набором значений ключа. Если это так, то это похоже на объектно-ориентированные базы данных, которые были опубликованы десять или два года назад; а также к базам данных XML/ документов и NoSQL.
Может быть, ACID транзакции (атомарность и т. Д.)? Но это не похоже на RDB.
Возможно, потому что реляционные базы данных позволили вам определить схему данных, которая была основана исключительно на данных - независимо от конкретного языка программирования, версии приложения (эволюции) или цели приложения (это делает "несоответствие импеданса" неизбежным). База данных со схемой данных имеет эту функцию.
Может быть, потому что реляционная модель математически обоснована? Но это не похоже на то, что это убедило бы менеджеров принять его - и какова будет выгода для бизнеса.
Может быть, потому что математическая модель дает вам возможность перестроить базу данных в разные нормальные формы, чтобы дать разные характеристики производительности, которые математически гарантированно не изменят значение данных? Это кажется правдоподобным, и мои учебники универмагов делают из этого большое дело, но это не кажется мне очень убедительным как практическая выгода для бизнеса (может, я что-то упускаю)?
Подводя итог: исторически, что заставило реляционную модель так решительно победить иерархическую модель? Меня также интересует, есть ли у RDB какое-то особое качество, которое делает их более практичным выбором для бизнеса (помимо преимуществ упомянутого выше стандарта).
Большое спасибо, если вы можете пролить немного света - мне давно было любопытно об этом.
5 ответов
По той же причине, почему языки сценариев популярны.
Вы можете сделать запрос в вашем любимом текстовом редакторе и просто выдать его, не беспокоясь о реальной физической схеме.
Это не самая быстрая модель, не самая надежная модель - это просто самая производительная модель. Вы можете написать в десять раз больше запросов в час.
Вы можете прочитать эту статью в моем блоге, в котором сравниваются самые популярные модели баз данных:
Концепция создания логического представления данных, абстрагированных от их физического представления, была, пожалуй, самым изменяющим игру аспектом идеи Кодда. Он был, очевидно, первым человеком, который полностью осознал преимущества разделения логических и физических проблем и, следовательно, первым, кто разработал модель данных, достойную этого имени. Описывая модель, основанную на отношениях, без навигационных ссылок или структур указателей, он также создал нечто уникально мощное, гибкое и долговременное.
Чтобы быть точным, нужно сказать, что именно модель SQL, а не реляционная, в конечном итоге оказалась более успешной в коммерческом отношении. SQL далек от подлинно реляционной модели данных или языка, даже если бы он не появился без идей Кодда, чтобы вдохновить его. Создатель реляционной модели, естественно, был разочарован тем, что SQL, а не реляционный стандарт, стал стандартом базы данных. Четыре десятилетия спустя, я думаю, у нас есть много причин сожалеть о том, что реляционная модель Кодда не лучше поддерживается программным обеспечением СУБД.
Я считаю, что ни один из ответов на самом деле не прибил его, так как вас интересует исторический аспект этого.
Если бы я выделил причину, я бы сказал, что Quassnoi был близок, но SQL - это не просто какой-либо язык - у него есть одна замечательная особенность, которая не была распространена в 70-х годах:
- он декларативный, он описывает, что вы хотите получить, и не прописывает, как это сделать.
Я не думаю, что это можно переоценить.
конечно, реляционная модель также является важным фактором (и связана с вышеизложенным)
- также не все базы данных, имеющие схему, относятся только к данным; Иерархические и сетевые базы данных также касаются способов получения данных, их структура определяет наиболее эффективный метод доступа к данным и, следовательно, влияет на структуру, как вы будете моделировать проблему (другими словами, на процесс моделирования влияет то, как приложение будет его использовать; эффект, что другое приложение, которое может нуждаться в использовании IMS, например, будет находиться в крайне неблагоприятном положении, или что некоторые изменения в приложении не потребуют изменений в структуре базы данных для достижения хорошей производительности - например, необходимость сортировать по некоторым новым колонка)
примечание: по некоторым из вышеперечисленных намерений SQL и R'DBMS не полностью доставили (и / или другие модели каким-то образом преодолели свои проблемы), но это были первоначальные намерения и с учетом того, насколько стабильным был SQL за последние ~40 лет (здесь это ссылка на статью IBM от 1974 года), или она тоже не сделала такую плохую, плохую работу.
Здесь также есть эта цитата
"Основная идея Теда заключалась в том, что отношения между элементами данных должны основываться на значениях элемента, а не на отдельно заданных связях или вложениях. Это понятие значительно упростило спецификацию запросов и позволило беспрецедентной гибкости использовать существующие наборы данных по-новому ", - сказал Дон Чемберлин, соавтор SQL, отраслевого стандарта языка для запросов к реляционным базам данных, и сотрудник отдела исследований в Almaden. "Он считал, что пользователи компьютеров должны иметь возможность работать на более естественном языке и не беспокоиться о деталях, где и как хранятся данные".
Во время воссоединения в 1995 году первых ученых IBM по реляционной базе данных Чемберлин вспомнил, что у него было прозрение, когда он впервые услышал, как Кодд описывает свою реляционную модель на внутреннем семинаре.
"У Кодда были довольно сложные вопросы", - сказал Чемберлин. "И поскольку я изучал CODASYL (язык, используемый для запросов к навигационным базам данных), я мог представить, как эти запросы были бы представлены в CODASYL программами длиной в пять страниц, которые могли бы перемещаться по лабиринту указателей и тому подобного. Кодд как бы записывал их как однострочники. ... (T) эй не было сложно вообще. Я сказал: "Вау". Это был своего рода опыт обращения для меня. После этого я понял, о чем идет речь.
Кажется, я помню стенограмму интересного интервью о попрошайничестве SQL, но не могу его отследить...
Насколько мне известно, это теория нормализации (хорошо известная третья нормальная форма Кодда) для определения реляционной модели данных, которую легко и эффективно хранить и извлекать. Затем следует стандартный язык запросов (SQL), который позволяет использовать его во всей реляционной системе БД. Тогда определенно отсутствовала стандартизация, что также делает это привлекательным для многих.
Одним из ключей были автономные продукты - вам больше не нужно было вручную определять и поддерживать ваши ключевые файлы (индексы) и возможность изменять модель данных с меньшими усилиями. Объедините это с основанными на SET структурами и сделайте его привлекательным продуктом для работы. Сочетание языка SQL для возврата данных, и это была беспроигрышная ситуация по сравнению с традиционными структурами данных ISAM, в первую очередь связанными с языками COBOL.