Comments 22
Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше.Когда первым же предложением понимаешь, что мало что понимаешь )
опять эта шляпа про таблицы, столбцы и ячейки... ппц.
если ты берешься рассуждать о реляционных базах данных с претензией на научность, то потрудись хотя бы теорию почитать. реляционная модель это не таблицы, столбики и ячейки. это прежде всего математический аппарат. и вся терминология берет свое начало в теории отношений. и все, что используется в рсубд это реализация этой модели.
не таблицы, а отношения, не строки, а кортежи, не имена столбцов, а предикаты отношений. и тд и тп. кроме представлений и индексов (которые нужны по совершенно по другим причинам, нежели, реализация процесса нормализации) одним и основопологающих элементов являются как раз таки сами отношения (буквп R в RDBMS) которые получаются путем декомпозиции в процессе нормализации данных, а выражаются они через ограничения целостности (первичные и внешние ключи) благодаря которым данные поддерживаются в непротиворечивом состоянии..
и это - только начало.
а потом, на выходе мы имеем безграмотных специалистов, не представляющих как данные вообще хранятся и как с ними работать.
хватит уже копипастить и плодить невежество! потрудитесь осилить хотя бы азы
Похоже автор сам не понимает про что написал...
Уясните для начала различия между терминами БД и СУБД.
SQL (МФА: [ˈɛsˈkjuˈɛl]; аббр. от англ. Structured Query Language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.
Реляционные БД появились задолго до того, как SQL вошел в широкий обиход. Вспомните 90-е годы - Clarion, dBase (и все на ее основе), Paradox... Все они были реляционными, но SQL тогда еще не было.
Сейчас, в той же DB2 for i есть два способа работы с БД - SQL (в т.ч. Embedded - возможность использовать SQL запросы, встроенные в код на других языках - С/С++б RPG, Cobol...) и "прямой доступ" - встроенные функции работы с таблицами в Cobol/RPG, библиотека RECIO для С/С++, позволяющие позиционировать, читать, изменять, добавлять, удалять данные в таблицах... Там даже кроме DDL есть свой язык - DDS - Data Defenition Specifications. И таблица ("физический файл") там рассматривается всего лишь как хранилище, а за доступ к нему отвечают "логические файлы", это могут бить как индексы (обычные или с дополнительными условиями-фильтрами), так и join-файлы, определяющие условия связывания двух и более таблиц.
И там SQL далеко не всегда является самым быстрым или самым эффективным способом работы с данными (хотя бы потому что любой запрос требует времени и ресурсов на подготовку - построение плана и т.п.)
С другой стороны, есть реализации SQL движка для нереляционных БД (та же Raima - RDM - Raima Data Manager, бывш. Velocis, бывш. dbVista - БД, использующая сетевую модель).
Короче говоря, статья очень поверхностная, скорее даже искажающая суть, чем что-то поясняющая.
Вспомните 90-е годы - Clarion, dBase (и все на ее основе), Paradox... Все они были реляционными, но SQL тогда еще не было.
Нееее, это неправильное утверждение. Вот эти вот три системы были реляционными но не поддерживали SQL - так правильно. Потому что SQL к тому времени уже примерно 20 лет как был, в 1983 на него был первый стандарт. И, например, одновременно с Paradox в 90-х годах использовались десктопные базы FoxPro, которые как раз сделаны на основе bBASE III и при этом имели SQL.
И до него уже был QBE. В том числе на мейнфреймах. И тоже раньше перечисленных. И в парадоксе кстати был он.
Вот эти вот три системы были реляционными но не поддерживали SQL - так правильно.
Да, согласен что неудачно сформулировал.
Просто мысль была в том, что реляционная БД - это реляционная БД, а SQL это SQL. Это всего лишь язык запросов, не более того. И не единственный, как указали ниже, упомянув QBE.
И язык запросов - не единственный способ получения информации из БД (в т.ч. реляционных). Можно и "прямым доступом", например (RPG, DB2 for i):
setll (index_value) index_file; // позиционируемся на нужное значение ключа
read index_file; // читаем запись на которую спозиционировались
dow not %eof(index_file); // тут можно какие-то дополнительные условия вводить
[...] // тут что-то делаем с прочитанной записью
read index_file; // читаем запись со следующим (или следующую с равным) значением ключа
enddo;и в ряде случаев это будет работать быстрее и тратить меньше ресурсов чем подготовка и выполнение SQL запроса
exec SQL select [нужные поля]
from data_file
where index_field = index_value;
"SQL: эти БД следуют требованиям ACID. ...
NoSQL: эти БД следуют требованиям теоремы CAP."
Эээээ...
Нереляционные — NoSQL.
Реляционные — SQL.
Вот объясните, почему если реляционная база, то сразу SQL? Есть ли какая-ни будь СУБД, которая, не отходя от реляционной модели, снимала бы ограничения SQL, например, делала бы обход графов? Тогда отпала бы необходимость в иерархических и графовых СУБД как отдельных продуктах. Я знаю, что обход графов можно делать рекурсивными SQL-запросами, но там есть ограничение глубины рекурсии и, наверное, это плохо оптимизируется.
Ну рекурсия скорее не в SQL, а в софтине, обращающейся к базе данных. Либо это серия join'ов, если надо, скажем, получить список всех правнуков какого-то узла, но тут кол-во join'ов фиксировано и ограничено, ну и сложно представить себе задачу, где надо выкачать сразу все на 20 уровней вглубь от интересующих данных.
Конечно, юмор в том, что все эти мега-достоинства NoSQL реализуются через SQL с помощью элементарных запросов, знакомых каждому с детства, и зачем городить что-то еще сверху - мне лично неведомо.
Говоря про рекурсию, я имел ввиду конструкцию WITH RECURSIVE. Насколько я понимаю, ее все-таки сервер обрабатывает. Вопрос, на сколько это эффективнее рекурсии или циклов в приложении.
Про "правнуков" я понимаю. А как вы предлагаете искать путь, длина которого заранее неизвестна? Какой такой знакомый с детства запрос тут пригодится? А это самая элементарная задача на графах
Автор оригинала: Enjon Podrimaj
A software engineer who finds writing short technical articles fun.
Кому фан, а кому потом выслушивать этот бред на собеседованиях. Если кому интересно, то в "книге с кабанчиком" гораздо более деликатный разбор вопроса. Но там и объем на порядок больше.
Сама поставновка вопроса в заголовке статьи неверная. Оба вида имеют свои особенности и свою область применения. Никто не ж не ставит вопрос "что лучше - лошадь или корова?"
Впечатление что статья писалась в начале нулевых, когда большинство SQL баз данных не масштабировались, хотя и тогда была Terradata. Сейчас когда есть BigQuery, Clickhouse, Snowflake (из аналитических) и Spanner, Cockroachdb (транзакционные) и многие другие, поддерживают SQL и хорошо горизонтально масшабируются читать это странно.
Верните мне время потраченное на это бесполезное чтение
В таблице Teacher имеются следующие атрибуты/столбцы:
- id — идентификатор конкретного учителя.
- ...
- class — внешний ключ (foreign key), который связывает ID конкретного класса с учителем.
А в таблице Class имеются такие столбцы:
- id — идентификатор класса.
- ...
- teacher — внешний ключ, связывающий ID учителя с классом.
Это — простой пример отношений таблиц, где имеется две таблицы, в каждой из которых имеются атрибуты, содержащие сведения об объекте. Эти два объекта связаны друг с другом с помощью связи многие-ко-многим (many-to-many).
Здесь нет отношения many-to-many. Автору двойка.
Откуда материал то брался для статьи?
С каких пор колоночные базы это nosql?
С каких пор горизонтальное масштабирование не доступно sql базам?
SQL и NoSQL. Правда ли одно лучше другого?