Как организовать данные, использующие JOIN?

@sKotenok · Регистрация: 29.03.2011

Author24 — интернет-сервис помощи студентам

Недавно начал знакомство с nosql-движками, пока эксперементирую. Решил сделать аналог существующей SQL базы.
Есть таблицы:

MySQL

CREATE TABLE `users` (
  `id` int AUTO_INCREMENT,
  `name` varchar,
-- ...
)
CREATE TABLE `users_block` (
  `user0` int,
  `user1` int,
  `block` int,
)
CREATE TABLE `orders` (
  `id` bigint AUTO_INCREMENT,
  `user0` int,
  `user1` int,
-- ...
)

И основной рабочий запрос (показываем юзеру заказы всех юзеров, кроме тех, кто ему явно запретил (есть запись в users_block)).:

MySQL

1
2
3

SELECT * FROM `orders` o LEFT JOIN `users_block` u 
ON (u.`user0`=o.`user0` AND u.`user1`='{user_id}')
WHERE u.`block` IS NULL AND --дальше фильтры по полям `orders`

Помогите организовать подобную логику на NoSQL (mongo или redis).

@korvin_ · 30.05.2013, 15:28

Не совсем понял, зачем в users_block поле block и зачем в orders два поля user.

И user0 и user1 стоило бы переименовать более осмысленно, типа owner(для orders) и т.д.

Разве это не то же самое, что и

MySQL

CREATE TABLE `users` (
  `id` int AUTO_INCREMENT,
  `name` varchar,
-- ...
)
CREATE TABLE `users_block` (
  `user` int,
  `blocked_user` int,
)
CREATE TABLE `orders` (
  `id` bigint AUTO_INCREMENT,
  `owner` int,
-- ...
)

MySQL

SELECT o.*
FROM `orders` o
WHERE o.`owner` NOT IN (SELECT `user` FROM `users_block` WHERE `blocked_user` = {user_id})
AND --дальше фильтры по полям `orders`

?

Если да, то примерно так (монго):

Javascript

// user document:
{
  name: <name>,
  blocks: [ <user_id> /* , ... */ ]
  // , ...
}
 
// order document:
{
  owner_user: ...,
  blocked_for: [<user_id> /* , ... */ ]
  // , ...
}

Соответственно выборка будет примерно такой (JS и монгу не очень хорошо знаю):

Javascript

1	db.orders.find({blocked_for: {$eq: <user_id> }})

Конечно при изменении списка блокировки придется обновлять все заказы пользователя.

Хорошее пояснение тут: http://stackoverflow.com/quest... ct-queries

Так же там есть предложение определить в БД функцию, если это работает, то можно получить список блокировки функцией и выбирать заказы примерно так:

Javascript

1	db.orders.find({owner: {$in: get_blockers() }})

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

@sKotenok · 30.05.2013, 23:49 **[ТС]**

korvin_, block использую как набор флагов, в данном запросе важно лишь наличие записи, в других местах разбирается содержимое: блокировку может поставить и user0 (не хочу видеть заказы user1) и user1 (не хочу видеть заказы user0), их начальник или админ (tiyint пока на всех хватает, если придётся ещё перегружать - поменяю на create_user). user0, user1 - это ForeignKey, называть их так во всех таблицах удобнее - сразу понятно, кто это и не надо потом вспоминать, что и как обозвал. Да, в orders 2 ссылки, потому-что создатель (user0) и исполнитель (user1) чаще всего разные (но может быть и один, тогда user1=user0).

Как я понял - вы предлагаете хранить информацию о блокировках прямо в заказе. Не раздует ли это базу почём зря? Пока читал ссылку, пришло в голову разбить запрос на 2:
а) Выбрать всех, чьи заказы user0 видеть не должен (можно хранить в таблице users)
б) Выбрать заказы, чей создатель не в первом списке.
На sql это делается средствами движка, чтобы данные зря не гонять, если запрос будет быстрее, почему нет?.
Позже проверю, что получилось.

@korvin_ · 31.05.2013, 08:13

Сообщение от sKotenok

Как я понял - вы предлагаете хранить информацию о блокировках прямо в заказе. Не раздует ли это базу почём зря?

Может и раздует, но это, в некотором смысле, «Mongo-way» — встраивание документов.

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	30.05.2013, 23:49 [ТС]	3
	korvin_, block использую как набор флагов, в данном запросе важно лишь наличие записи, в других местах разбирается содержимое: блокировку может поставить и user0 (не хочу видеть заказы user1) и user1 (не хочу видеть заказы user0), их начальник или админ (tiyint пока на всех хватает, если придётся ещё перегружать - поменяю на create_user). user0, user1 - это ForeignKey, называть их так во всех таблицах удобнее - сразу понятно, кто это и не надо потом вспоминать, что и как обозвал. Да, в orders 2 ссылки, потому-что создатель (user0) и исполнитель (user1) чаще всего разные (но может быть и один, тогда user1=user0). Как я понял - вы предлагаете хранить информацию о блокировках прямо в заказе. Не раздует ли это базу почём зря? Пока читал ссылку, пришло в голову разбить запрос на 2: а) Выбрать всех, чьи заказы user0 видеть не должен (можно хранить в таблице users) б) Выбрать заказы, чей создатель не в первом списке. На sql это делается средствами движка, чтобы данные зря не гонять, если запрос будет быстрее, почему нет?. Позже проверю, что получилось. 0

@korvin_ 4486 / 2721 / 485 Регистрация: 28.04.2012 Сообщений: 8,590
	31.05.2013, 08:13	4
	Сообщение от sKotenok Как я понял - вы предлагаете хранить информацию о блокировках прямо в заказе. Не раздует ли это базу почём зря? Может и раздует, но это, в некотором смысле, «Mongo-way» — встраивание документов. 0