SQL - вложенный оператор выбора?

Question

У меня есть 2 стола, тикет и ticket_custom.
Вот как настраиваются таблицы.

У меня есть веб-интерфейс, где я могу изменить состояние (значение в таблице ticket_custom). Веб-интерфейс добавляет новую запись вместо обновления исходной.

ticket  name    value
1   state   Ready for Final Verification
2   state   Ready for Final Verification
1   state   Verified                      

Добавлена ​​последняя строка

Так что мне нужно изменить запросы.

   SELECT p.value AS __color__,
   id AS ticket, summary, component, version, c.value AS state, milestone, t.type AS type, 
   owner, status,
   time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t,  ticket_custom c
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority' AND id = c.ticket
  WHERE status <> 'closed' AND id = c.ticket
  ORDER BY CAST(p.value AS int), milestone, t.type, time, c.ticket 

Запрос теперь возвращает обе записи. Я попытался добавить вложенный выбор в предложении where.

SELECT g.ticket
FROM ticket_custom g
WHERE g.ticket = id
ORDER BY g.ticket DESC LIMIT 1

Итак -

SELECT p.value AS __color__,
   id AS ticket, summary, component, version, c.value AS state, milestone, t.type AS type, 
   owner, status,
   time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t,  ticket_custom c
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority' AND id = c.ticket
  WHERE status <> 'closed' AND id = c.ticket and (
         SELECT g.ticket
         FROM ticket_custom g
         WHERE g.ticket = id
         ORDER BY g.ticket DESC LIMIT 1 )
  ORDER BY CAST(p.value AS int), milestone, t.type, time, c.ticket

Очевидно, что я делаю что-то не так.

Answer 1

Похоже, что это скорее проблема дизайна, чем проблема запроса. Хотя можно вернуть только одну запись из таблицы ticket_custom, нет способа определить, какая это будет запись. В вашем примере таблицы 1 билет имеет значения «Готов к ...» и «Проверено», но ничего не показывает, что произошло первым. По логике вещей, «Готов к ...» произошло первым.

Самый простой способ решить эту проблему - добавить поле метки времени или увеличивающегося идентификатора. Тогда ваш подзапрос может выбрать самую последнюю запись (последнюю временную метку или самый высокий идентификатор).

Answer 2

Предполагая, по крайней мере, один билет, вы могли бы сделать это вместо:

ВЫБЕРИТЕ МАКС (g.ticket) ОТ тикета ГДЕ g.ticket = id

Вы можете преобразовать это в JOIN или вложенный SELECT и т. Д.

поэтому измените id = c.ticket id = MAX (c.ticket)

но проверь, ГДЕ И СЛЕДУЮЩЕЕ СОЕДИНЕНИЕ есть там какие-то странные вещи.

Answer 3

Не делайте вашу схему базы данных динамической (то есть "управляемой таблицей"). Это не разумный шаблон дизайна (я знаю из опыта). При создании дополнительных атрибутов экономится всего лишь небольшое предварительное усилие, но впоследствии возникают дополнительные издержки, как при написании запросов, так и при обработке базы данных, необходимой для их выполнения.

Просто добавьте столбец идентификатора состояния в таблицу заявок и обновите его при изменении состояния. Создайте справочную таблицу для хранения названий состояний. Тогда ваши запросы станут довольно простыми, и ядру базы данных потребуется меньше усилий для индексного соединения с небольшой справочной таблицей.