Является ли inner_join в R таким же, как inner join в SQL?

#sql #r #dplyr #vertica

#sql #r #dplyr #vertica

Вопрос:

Когда я считываю таблицы из Vertica DB в R как dataframes и выполняю inner_join, я получаю разные результаты по сравнению с выполнением inner join для этих двух таблиц в Vertica на тех же условиях соединения. Есть ли что-то, что R делает inner join иначе, чем SQL join?

Комментарии:

1. Добро пожаловать в Stack Overflow. Если синтаксис правильно сформирован, dplyr::inner_join выполняет то же самое, что и внутреннее соединение SQL. Разница, скорее всего, в «by =» против «on». Можете ли вы поделиться кодом, который вы пытаетесь, вместе с некоторыми примерами данных?

Ответ №1:

Как правило, два разных ядра баз данных должны выдавать одинаковые результаты для одного и того же запроса к одним и тем же данным. В этом есть некоторые нюансы. Некоторые вещи, которые приходят на ум:

Во-первых, порядок результирующих наборов может отличаться, если order by не указан an и order by ключи не являются уникальными.

Во-вторых, чувствительность к регистру по умолчанию может отличаться. Итак, в одной базе данных строки можно сравнивать, различая верхний и нижний регистры.

Третье соображение является продолжением второго: параметры сортировки строк могут отличаться, и это может повлиять на результаты сравнения.

Для чисел у вас могут быть разные внутренние представления — например, 32-разрядные числа с плавающей точкой или 64-разрядные числа с плавающей точкой. Однако использование чисел с плавающей запятой в соединениях крайне не рекомендуется, поскольку они являются «нечеткими», а не точными значениями.

Сравнения Datetime / timestamp могут отличаться из-за точности секунд — миллисекунды против наносекунд, например. Сравнение дат должно быть одинаковым, но преобразования по умолчанию из строк в даты могут отличаться.

Без сомнения, есть и другие тонкости. Идея заключается в том, что код должен быть одинаковым, но существуют экологические соображения относительно того, действительно ли два значения, равные в одной базе данных, равны в другой.

Комментарии:

1. Хороший, казалось бы, полный список проблем (это означает, что я больше ничего не могу придумать). Справедливо ли объединять сравнения временных меток с плавающими значениями? Часто это один и тот же аргумент, основанный на IEEE-754 или связанный (если только DMBS не использует какой-либо другой механизм хранения).