SQLite запрос упорядочен по критериям в другой таблице? - PullRequest
2 голосов
/ 19 апреля 2011

У меня есть таблица «products» базы данных SQLite со списком товаров, каждый из которых имеет категорию и предполагаемую прибыль. Что-то вроде

|id | product  | category_id  | profit | customer_id |
|---|----------|--------------|--------|-------------|
| 1 | product1 | 1            | 15     | 0           |
| 2 | product2 | 2            | 10     | 0           |
| 3 | product3 | 1            |  9     | 0           |
| 4 | product4 | 2            | 12     | 0           |

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

|id | name        | category_id  | order |
|---|-------------|--------------|-------|
| 1 | customer1   | 2            | 1     |
| 2 | customer2   | 1            | 2     |
| 3 | customer3   | 1            | 3     |

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

|name        | product      | profit |
|------------|--------------|--------|
|customer1   | product4     | 12     |
|customer2   | product1     | 15     |
|customer3   | product3     |  9     |

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

Например

SELECT customers.name, products.name, products.profit
  FROM customers INNER JOIN products ON customers.category_id = products.category_id
  ORDER BY customers.order, products.profit

просто дает мне список всех клиентов, перешедших со всеми продуктами:

|name        | product      | profit |
|------------|--------------|--------|
|customer1   | product4     | 12     |
|customer1   | product2     | 10     |
|customer2   | product1     | 15     |
|customer2   | product3     |  9     |
|customer3   | product1     | 15     |
|customer3   | product3     |  9     |

Можете ли вы помочь мне с правильным запросом, чтобы написать?

ОБНОВЛЕНИЕ: отредактировал таблицы выше, чтобы включить некоторые идеи из ответа. Предполагая, что products.customer_id = 0 указывает на невыбранный продукт, я могу написать следующий запрос.

UPDATE products SET customer_id = customers.id 
WHERE products.customer_id = 0 AND products.category_id = customers.category_id

Я не ожидаю, что это будет работать именно так, как я хочу, потому что это еще не относится к столбцу прибыли, и я не уверен, как этот запрос фактически обрабатывает wrt customer_id. Я проверю это и отвечу обратно.

1 Ответ

1 голос
/ 24 апреля 2011

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

Как насчет добавления столбца 'user_id' в продуктах, который указывает, какой пользователь выбрал его.

Если данный продукт может быть выбран только одним пользователем, вам нужно каким-то образом узнать, кто его уже выбрал и кем. Возможно, я неправильно понимаю, что вы здесь делаете, но похоже, что вы пытаетесь объединить выбор продукта (который зависит от предпочтительной категории, максимальной прибыли и того, что уже было выбрано) с дополнительным этапом запроса результатов. Вероятно, вам придется разбить этот шаг на два этапа:

  1. В вашем коде определите, кто какой продукт получает по вашим критериям, и пометьте их как таковые в базе данных.
  2. Запустить запрос результатов.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...