Хранилище объектов данных - Может ли таблица JOIN делать то, что не может сделать одна таблица SELECT?
Теперь, когда системы хранения "NOSQL" или "только объект", такие как MongoDB или memcached, действительно набирают обороты в мире. Мне было интересно, есть ли какие-либо запросы, которые не могут быть выполнены над ними, которые могут быть выполнены с использованием нескольких объединений объектов (в SQL это JOIN "таблица" ). Другими словами, существуют ли какие-либо многотабличные запросы, которые не могут быть обработаны несколькими одиночными табличными запросами подряд?
По сути, есть ли вариант использования, когда многостолбовое соединение не может быть реплицировано путем доступа к одной таблице в время в объектно-ориентированных системах хранения?
Вот несколько примеров обычных запросов 3NF с использованием отношений has_man и has_many_through. Это не t самые сложные запросы - но они должны дать вам отправную точку для концепции. Обратите внимание, что любое значение в {} означает значение результата последнего запроса.
В компании много пользователей
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.
Пока что, похоже, единственно неправильным является то, что нужно больше запросов.
4 ответа
1 — выполнение нескольких отдельных запросов оставляет вас в беспорядке параллелизма — к тому времени, когда вы получили что-то из таблицы 1, оно могло быть удалено и все еще могло быть в таблице 2 — теперь предположим, что 5 коррелированных таблиц.
2 - выполнение запросов с как минимум умеренно сложной логикой над полями, которые не являются мифическим идентификатором
3 - контроль количества извлекаемых данных (вам вряд ли понадобится более 50% данных, необходимых для десериализации/создания допустимые объекты и, что еще хуже, целые деревья связанных объектов)
4 - коррелированные запросы (вложенные выборки), которые SQL-сервер будет оптимизировать как соединения с аддитивной сложностью или лучше (|T1|+|T2|+|T3|+|T4| ), в то время как любой ORM или неSQL должен будет продолжать повторять внутренние запросы и приводить к мультипликативной сложности (|T1||T2||T3|*|T4|)
5 — размеры наборов данных, масштабируемость не только в размерах наборов данных, но и в обработке параллелизма при обновлениях. Даже ORM, которые поддерживают транзакции, делают их настолько длинными, что вероятность взаимоблокировок возрастает в геометрической прогрессии.
6 - слепые обновления (намного больше данных затрагивается без причины) и их зависимость и сбои на основе слепого инструмента (мифическая версия, которая реально необходима, скажем, в 1% реляционной модели данных, но ORM и тому подобное должны иметь это везде)
7 - отсутствие каких-либо стандартов и совместимости - это означает, что ваша система и данные всегда будут подвергаться гораздо большему риску и зависеть от изменений программного обеспечения, вызванных академическим авантюризмом, а не какой-либо реальной деловой ответственностью и с расчетом на большие инвестиции. ресурсов только при тестировании изменений.
8 - целостность данных - упс, какой-то код только что удалил половину записей сегодняшнего заказа из T1, так как не было внешнего ключа для T2, чтобы остановить это. Prefecly нормальная вещь, чтобы сделать с разделенными запросами.
9 - отрицательный тренд зрелости - продолжает дробиться вместо стандартизации - дайте ему 20 лет, и, возможно, он станет стабильным
И последнее, но не менее важное - это не снижает сложности (такая же корреляция между данными все еще существует) но это очень затрудняет отслеживание и управление сложностью или получение каких-либо реальных средств или прозрачности, когда что-то идет не так. И это добавляет сложности в 1-2 слоя. Если что-то пойдет не так в ваших таблицах SQL, у вас есть инструменты и запросы для обнаружения и даже исправления ваших данных. Что вы собираетесь делать, когда какая-то ORM просто сообщает вам, что у нее есть «недопустимый указатель», и выдает исключение, поскольку, конечно же, вам не нужен «недопустимый объект»?
Думаю, хватит :-)
Если вы можете, это не значит, что вы должны.
Альтернативные минусы множественного оператора SELECT:
- чем меньше обращений к базе данных, тем лучше. Накладные расходы TCP не могут быть возмещены, и похоже, что сетевой нейтралитет официально мертв, так что мы можем ожидать движения в сторону от multi-select/nosql, потому что вам, возможно, придется платить за эту пропускную способность...
- из-за задержки между начальным и последующими запросами, риск того, что вспомогательные данные не будут отражать то, что было в системе на момент выполнения первого запроса
- меньшая масштабируемость - чем больше набор данных, тем больше работы приложение делает над бизнес-правилами и ассоциациями, которые гораздо лучше масштабируются в базе данных
- большая сложность приложения, что также делает бизнес менее переносимым (IE: переходите с Java на . NET или наоборот - вам придется создавать приложение с нуля, в то время как бизнес-логика в БД свела бы это к минимуму)
Вы также можете использовать nosql как старомодную «иерархическую» базу данных!
Помимо ответов OMGPonies, составить отчет труднее.
Насчет масштабирования - это не так. nosql предназначен для масштабирования, если вы правильно его используете.
Еще одна причина использовать nosql - если вы выполняете всю свою работу с объектами, выполняя сопоставление с sql, и не выполняете сложных (т. Е. Выполняемых вручную для повышения эффективности) операторов UPDATE. например, обновление соединения или обновление 'where ... in (...)'.
Если база данных является одноцелевой (обычно в случае приложений большого объема), nosql, скорее всего, будет в порядке.
Многоцелевой - OLTP - направление бизнеса - переходите к SQL.
Я мог бы продолжить, но сейчас перерыв на обед. Не то чтобы я когда-либо ел в рабочее время. Я предпочитаю просто есть во время обеденного перерыва.
На самом деле одна из самых больших проблем заключается в том, что некоторые базы данных NoSQL не являются транзакционными для нескольких запросов. ORM, такой как Hibernate, иногда будет выполнять несколько запросов без «присоединения», но имеет то преимущество, что они находятся в одной транзакции.
С NoSQL у вас нет такой роскоши. Таким образом, это может очень легко привести к вводящим в заблуждение результатам:
SELECT * FROM user WHERE id = 4
SELECT * FROM company WHERE id = {user.comany_id}
Если компания для user.company_id удаляется между вызовами двух инструкций. Это хорошо известная проблема с этими базами данных. Таким образом, независимо от того, можете ли вы правильно выполнять JOIN, проблема будет заключаться в отсутствии транзакций.
В противном случае вы можете моделировать что угодно, лишь бы оно могло хранить байты :)