Какие инновации в реляционных базах данных появились за последние 10 лет

Реализация реляционных баз данных SQL в нынешнем виде существует уже около 25 лет (со времен System R и Ingres). Даже основному (слабо соблюдаемому) стандарту является ANSI-92 (хотя были и более поздние обновления), которому уже 15 лет.

Какие инновации вы можете придумать для баз данных на основе SQL за последние десять лет или около того. Я специально исключаю OLAP, Columnar и другие нереляционные (или, по крайней мере, не SQL) инновации. Я также хочу исключить функции и комплектации типа «сервер приложений» (например, инструменты отчетности).

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

  • Доступность
  • Возможность обрабатывать большие наборы данных
  • Легкость обслуживания и настройки
  • Поддержка более продвинутых типов данных (blob, xml, unicode и т. д.)

Есть ли другие, о которых вы можете подумать?

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
8
0
1 130
9
Перейти к ответу Данный вопрос помечен как решенный

Ответы 9

Я не уверен, хотите ли вы включить даже нововведения, специфичные для конкретного поставщика (и я не совсем уверен, что другие механизмы баз данных уже не могут этого сделать), но SQL Server 2005 добавляет к своему языку рекурсивные запросы transact-sql. Я считаю их чрезвычайно полезными для перебора иерархических данных. Я считаю, что в 2008 году добавлены некоторые новые функции, связанные с иерархическими данными, но я не смотрел так внимательно.

Конкретный поставщик определенно важен - в конце концов, именно в этом и появились инновации с момента выхода стандарта ANSI92.

Simon Munro 10.10.2008 20:04

Общие табличные выражения принесут поддержку рекурсивных запросов в PostgreSQL в версии 8.4 (еще не вышла). Ура, рекурсия! wiki.postgresql.org/wiki/CTEReadme

Neall 11.10.2008 00:32

Аналитические функции, такие как RANK

SELECT (invoiceprice * detailweight) / SUM(weight) OVER(PARITTION BY invoice) as weighted, * 
FROM tblInvoiceDetails

Оконные функции отлично подходят для выполнения таких вещей, как средневзвешенные значения, и других вещей, которые ранее требовали КУРСОРОВ.

Я думаю, что большая часть прогресса была достигнута в области производительности - профилировщиков запросов и кластеров.

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

Я бы сказал, что за последние десять лет (1998-2008) продукты РСУБД с открытым исходным кодом стали жизнеспособными в массовых развертываниях. Большинство компаний из списка Fortune 500 теперь используют MySQL, PostgreSQL или другую СУБД с открытым исходным кодом где-то в своей организации, даже если они также используют одну из коммерческих марок СУБД с закрытым исходным кодом.

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

Я понимаю, что и MySQL, и PostgreSQL были доступны еще в 1995 году, но я утверждаю, что они не были широко распространены в течение нескольких лет после этого.

Я думаю, что область наибольших инноваций, вероятно, связана с репликацией данных - для обеспечения доступности и надежности. Большинство других областей более инкрементальное. Указав десятилетие, вы опускаете материал ORDBMS - расширяемость; появившийся в 1997 году.

Ответ принят как подходящий
  • Хеш присоединяется
  • Оптимизаторы на основе затрат (в значительной степени перевернувшие написание запросов с ног на голову)
  • Разбиение на разделы (позволяет намного лучше управлять VLDB)
  • Параллельная (многопоточная) обработка запросов
  • Кластеризация (не только доступность, но и масштабируемость)
  • Большая гибкость в SQL, а также более простая интеграция SQL с языками 3GL
  • Улучшенные возможности диагностики

Я помню реляционную СУБД с хорошим оптимизатором на основе затрат в 1980-х годах.

Walter Mitty 17.02.2009 00:12

Наряду со списком более сложных типов данных (blob, xml, unicode и т. д.) Вы должны включить пространственные типы.

Расширение PostGIS для PostgreSQL вышло в 2001 году, но теперь все основные поставщики реализовали пространственные объекты и пространственный SQL.

Наряду с распространением Google Maps, Bing Maps и OpenLayers возможность отображать геопространственные данные и выполнять пространственные запросы без промежуточного программного обеспечения оказала огромное влияние на Интернет и анализ данных.

Другие вопросы по теме