Предположим, я создаю блог, в котором я хочу иметь посты и комментарии. Поэтому я создаю две таблицы: таблицу «posts» с автоинкрементным целочисленным столбцом «id» и таблицу «comments» с внешним ключом «post_id».
Затем я хочу выполнить то, что, вероятно, будет моим самым распространенным запросом, а именно: получить сообщение и все его комментарии. Будучи довольно новым для реляционных баз данных, подход, который кажется мне наиболее очевидным, заключается в написании запроса, который будет выглядеть примерно так:
SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7
Который дал бы мне идентификатор и содержание сообщения, которое я хочу, вместе со всеми соответствующими строками комментариев, аккуратно упакованными в массив (вложенное представление, которое вы использовали бы в JSON). Конечно, SQL и реляционные базы данных не работают таким образом, и самое близкое, что они могут получить, это объединить «посты» и «комментарии», которые будут возвращать много ненужного дублирования данных (с повторением одной и той же информации поста). в каждой строке), что означает, что время обработки тратится как на базу данных, чтобы собрать все это вместе, так и на мой ORM, чтобы проанализировать и отменить все это.
Даже если я проинструктирую свой ORM с нетерпением загружать комментарии к записи, лучшее, что она сделает, - отправит один запрос к сообщению, а затем второй запрос, чтобы получить все комментарии, а затем соединит их вместе на стороне клиента, что тоже неэффективно.
Я понимаю, что реляционные базы данных являются проверенной технологией (черт, они старше меня), и что за эти десятилетия в них было проведено множество исследований, и я уверен, что есть действительно веская причина, почему они (и Стандарт SQL) предназначены для того, чтобы функционировать так, как они, но я не уверен, почему описанный выше подход невозможен. Мне кажется, это самый простой и очевидный способ реализации одного из самых основных отношений между записями. Почему реляционные базы данных не предлагают что-то подобное?
(Отказ от ответственности: я в основном пишу веб-приложения с использованием хранилищ данных Rails и NoSQL, но недавно я пробовал Postgres, и мне это очень нравится. Я не хочу атаковать реляционные базы данных, я просто озадачен.)
Я не спрашиваю, как оптимизировать приложение Rails или как обойти эту проблему в конкретной базе данных. Я спрашиваю, почему стандарт SQL работает таким образом, когда он кажется мне нелогичным и расточительным. Должна быть какая-то историческая причина, по которой первоначальные разработчики SQL хотели, чтобы их результаты выглядели так.