Использование JOINs против IN/NOT IN для удобочитаемости

Позвольте мне предисловие к этому, сказав, что это не вопрос эффективности.Использование JOINs против IN/NOT IN для удобочитаемости

Скажем, ради аргумента у меня есть база данных с двумя таблицами: «Пользователи и роли».

Пользователи выглядит следующим образом:

Username Password FirstName LastName 
-------- -------- ---------- --------- 
braab  pass1234 Braab  Himself 
joe   pass1257 Joe   Smith 
robert  pass1235 Robert  Irvine 
kelly  pass1236 Kelly  Clarkson

Роли выглядит следующим образом:

Username Role 
-------- ---- 
braab  admin 
robert  customer 
kelly  developer 
joe   admin

Я хочу, чтобы найти и фамилии всех пользователей, имеющих роль «администратора».

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

В методе:

select 
    firstname, lastname 
from 
    users 
where 
    username in 
     (select 
      username 
     from 
      roles 
     where 
      role = 'admin' 
     )

РЕГИСТРИРУЙТЕСЬ Метод:

select 
    user.firstname, user.lastname 
from 
    users as user 
inner join 
    roles as role 
on 
    user.username = role.username

Какой путь более ясно, что я пытаюсь найти первые и последние имена пользователей администратора? Есть ли предполагаемое использование? Для меня эта статья является наиболее ясной для достижения поставленной цели.

В зависимости от вашего опыта/обучения с использованием SQL, я вижу, что это происходит в любом случае. Мое беспокойство заключается в том, что я хочу, чтобы другие разработчики могли понять, какую цель я пытаюсь достичь.

источник

2015-12-02 braab

Помните, что 'NOT IN' может быть сложным, если подзапрос может возвращать' NULL'. Я бы использовал 'JOIN' над' IN/NOT IN', особенно когда подзапрос коррелирован. – lad2025

Может ли один пользователь иметь несколько ролей? В противном случае лучше добавить поле в таблицу «Пользователи». –

Эти два утверждения не обязательно возвращают одно и то же, например. когда пользователь может иметь более одной роли –

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

Как вы можете видеть в этом документе SQL Fiddle Demo планы выполнения различны. Порядок в том, какие таблицы являются процессом, отличается. Поскольку таблицы являются небольшим индексом, не становятся фактором, но это также влияет на вариант, который вы используете.

источник

2015-12-02 15:56:25

Это проблема. Если другой разработчик должен поддерживать мой код, важно понимать, что я делаю. Производительность важна, но так же читаемость. StackOverflow уже загружен вопросами эффективности. Я хотел бы знать, какие из двух вышеперечисленных вопросов были наиболее ясными в достижении цели в этом примере. – braab

@braab оба одинаково понятны, так что больше похоже на то, какой стандарт вы следуете. Мне нравится использовать больше 'JOIN', чем' IN'. потому что меньше строк кода. –

FWIW, это было бы мое заявление о выборе. Краткий, читаемый код и комментарий для тех, кто не хочет читать код.

-- get first and last name of all users who have the 'admin' role 
SELECT users.firstname 
    , users.lastname 
FROM users 
INNER JOIN roles 
    ON users.username = roles.username 
WHERE roles.Role = 'admin'

Как я уже писал в комментариях, как только вы выходите за пределы 2-й или, может быть, 3 таблиц, JOIN и намного лучше, чем IN подзапросов для удобства чтения.

источник

2015-12-02 17:02:22 Andre

Использование JOINs против IN/NOT IN для удобочитаемости

ответ

Смежные вопросы