Хранилище объектов данных - может ли таблица JOIN делать то, что не может делать одна таблица SELECT?

Question

Теперь, когда системы хранения "NOSQL" или "только объект", такие как MongoDB или memcached, действительно набирают обороты в мире.Мне было интересно, есть ли какие-либо запросы, которые не могут быть выполнены над ними, которые могут быть выполнены с помощью объединения нескольких объектов (в SQL это JOIN "table").Другими словами, существуют ли какие-либо запросы к нескольким таблицам, которые не могут быть обработаны несколькими запросами к одной таблице подряд?

По существу, существует ли сценарий использования, при котором объединение в несколько таблиц невозможно реплицироватьобращаясь к одной таблице за раз в объектно-ориентированных системах хранения?

Вот несколько примеров обычных запросов 3NF , использующих отношения has_man и has_many_through.Это не самые сложные запросы, но они должны дать вам отправную точку для концепции.Обратите внимание, что любое значение в {} означает значение результата последнего запроса.

---

Компания имеет много пользователей

SELECT user.*, company.name as company_name FROM user 
LEFT JOIN company ON company.id = user.company_id
WHERE user.id = 4

против

SELECT * FROM user WHERE id = 4
SELECT * FROM company WHERE id = {user.comany_id}

---

В клубе много учеников

SELECT student.* FROM student LEFT JOIN membership on
membership.student_id = sudent.id WHERE membership.club_id = 5

против

SELECT * FROM membership WHERE club.id = 5
SELECT * FROM student WHERE id = {membership.student_id}

Мне интересно, потому что я хочузнать, могут ли основанные на объектах системы (которые полагаются на одновременный доступ к объектам одной таблицы) делать то, что могут делать базы данных RDBMS, такие как PostgreSQL или MySQL.

Пока что, похоже, единственно неправильным является то, что необходимо больше запросов.

Answer 1

То, что вы можете , не означает, что вы должны .

Множественная альтернатива оператора SELECT минус:

• чем меньше поездок в базу данных, тем лучше. Накладные расходы TCP не могут быть возмещены, и похоже, что Сетевой Нейтралитет официально мертв 1012 *
• из-за задержки между начальным и последующим операторами, риск поддержки данных, не отражающих то, что было в системе при запуске первого запроса
• менее масштабируемо - чем больше набор данных, тем больше работы приложение выполняет для работы с бизнес-правилами и ассоциациями, которые могут значительно лучше масштабироваться в базе данных
• сложность в приложении, что также делает бизнес менее переносимым (IE: переход с Java на .NET или наоборот - вы смотрите на создание с нуля, когда бизнес-логика в БД минимизирует это)

Answer 2

1 - выполнение нескольких разделенных запросов оставляет вас в беспорядке, когда вы получаете что-то из таблицы 1, оно может быть удалено и все еще находится в таблице 2 - теперь предположим, что есть 5 взаимосвязанных таблиц.

2 - выполнение запросов с, по крайней мере, умеренно сложной логикой над полями, которые не являются мифическим идентификатором

3 - контроль количества извлекаемых данных (вам вряд ли когда-либо понадобится более 50% данных, необходимых для десериализации / созданиядопустимые объекты и, что еще хуже, целые деревья связанных объектов)

4 - коррелированные запросы (вложенные выборки), которые SQL-сервер будет оптимизировать, например, для объединения сложностей или лучше (| T1 | + | T2 | + | T3 | +| T4 |) в то время как любой ORM или nonSQL должен будет повторять внутренние запросы и создавать мультипликативную сложность (| T1 | | T2 | | T3 | * | T4 |)

5- размеры наборов данных, масштабируемость не только в размерах наборов данных, но и в обработке параллелизма при обновлениях.Даже ORM-ы, которые поддерживают транзакции, делают их такими длинными, что шансы на взаимоблокировки увеличиваются экспоненциально.

6 - слепые обновления (гораздо больше данных затрагиваются без причины), а также их зависимость и сбой на основе слепого инструмента (мифическийверсия, которая реально необходима, скажем, в 1% реляционной модели данных, но ORM и другие должны иметь ее везде)

7 - отсутствие каких-либо стандартов и совместимости - это означает, что ваша система и данные всегда будут в значительной степениболее высокий риск и зависит от изменений программного обеспечения, вызванных академическим авантюризмом, а не какой-либо реальной деловой ответственностью и с ожиданием инвестировать много ресурсов только в тестирование изменений.Закажите записи из T1, так как не было никакого внешнего ключа для T2, чтобы остановить его.Обычно это обычная вещь для отдельных запросов.

9 - отрицательный тренд зрелости - вместо стандартизации продолжается расщепление - дайте ему 20 лет и, возможно, он станет стабильным

Последнее, но не менее важное - это не такНе уменьшайте всю сложность (такая же корреляция между данными все еще существует), но это очень усложняет отслеживание и управление сложностью, а также дает какие-либо реалистичные меры или прозрачность, когда что-то идет не так.И это добавляет сложности 1-2 слоя.Если что-то идет не так в ваших таблицах SQL, у вас есть инструменты и запросы для обнаружения и даже исправления ваших данных.Что вы будете делать, когда какой-то ORM просто скажет вам, что у него есть «неверный указатель» и выдает исключение, так как вы наверняка не хотите «неверный объект»?

Я думаю, этого достаточно: -)

Answer 3

На самом деле одна из самых больших проблем заключается в том, что некоторые базы данных NoSQL не являются транзакционными для нескольких запросов.ORM, такой как Hibernate, будет выполнять несколько запросов без «объединения», но будет иметь преимущество, заключающееся в одной транзакции.

С NoSQL у вас нет такой роскоши.Так что это может очень легко привести к неверным результатам:

SELECT * FROM user WHERE id = 4
SELECT * FROM company WHERE id = {user.comany_id}

Если компания для user.company_id будет удалена между двумя вызовами операторов.Это хорошо известная проблема с этими базами данных. Таким образом, независимо от того, можете ли вы правильно выполнять СОЕДИНЕНИЯ, проблема не будет иметь транзакций.

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

Answer 4

Вы также можете nosql, как старомодная «иерархическая» база данных!

В дополнение к ответам OMGPonies составлять отчеты труднее.

По поводу масштабирования - это неправильно.nosql предназначен для масштабирования, если вы правильно его используете.

Еще одна причина сделать nosql - если вы выполняете всю свою работу с объектами, выполняете или сопоставляете ее с sql, и не выполняете сложную (т. Е. Выполняющуюся вручную для повышения эффективности) инструкцию UPDATE.например, обновление объединения или обновление 'where ... in (...)'.

Если база данных одноцелевая (как, например, для приложений большого объема), nosql более вероятенбыть в порядке.

Многоцелевой - OLTP - бизнес - иди с SQL.

Я мог бы продолжить, но это перекусывает в мой обеденный перерыв.Не то, чтобы я когда-нибудь ел в рабочее время.Я предпочитаю просто есть во время обеденного перерыва.