Проблема “GROUP BY” SQL
Подобный как выше...
у меня есть изменить размер обработчик событий, который инициирован каждый раз, когда окно изменено (Максимизируемый, минимизированный, и т.д.)...
public form1()
{
Initialize Component();
this.Resize += new EventHanlder(form1_Resize);
}
private void form1_Resize(object sender, EventArgs e)
{
if (this.WindowState == FormWindowState.Minimized && minimizeToTrayToolStripMenuItem.Checked == true)
{
NotificationIcon1.Visible = true;
NotificationIcon1.BalloonTipText = "Tool Tip Text"
NotificationIcon1.ShowBalloonTip(2); //show balloon tip for 2 seconds
NotificationIcon1.Text = "Balloon Text that shows when minimized to tray for 2 seconds";
this.WindowState = FormWindowState.Minimized;
this.ShowInTaskbar = false;
}
}
Это позволяет пользователю выбирать, хотят ли они минимизировать к лотку через строку меню. Они могут перейти к Windows-> и нажимать на Minimize to Tray. Если это будет проверено, и окно изменяется к Минимизированному, то оно минимизирует к лотку. Работы безупречно для меня.
7 ответов
Причина, по которой вы получаете произвольную цену, состоит в том, что mysql не может знать, какие столбцы выбрать, если вы GROUP BY что-то. Он знает, что ему нужна цена и дата для каждого pid-идентификатора, и может получить самую последнюю дату по вашему запросу с помощью max (date) , но предпочитает возвращать цену, которая наиболее эффективно для него извлекать - вы не предоставили агрегатную функцию для этого столбца (на самом деле ваш первый запрос не является допустимым SQL).
Ваш второй запрос выглядит нормально, но вот более короткая альтернатива:
SELECT pid, price, date
FROM ProductPrice p
WHERE date = (SELECT MAX(date) FROM ProductPrice tmp WHERE tmp.pid = p.pid)
Но если вы часто обращаетесь к последней цене (что, я думаю, у вас есть), я бы рекомендовал добавить старый столбец обратно в исходную таблицу, чтобы сохранить новейшее значение,
Я думаю, вы нарушили схему своей базы данных.
Чтобы обойти проблему старых счетов-фактур, показывающих неточные цены после изменения цены продукта, я переместил поле цены из таблицы Product в ProductPrice таблица, состоящая из 3 полей: pid, дата и цена. pid и дата образуют первичный ключ для таблицы.
Как вы указали, вам необходимо вести историю изменений цен. Но вы все равно можете сохранить текущую цену в таблице продуктов в дополнение к этой новой таблице. Это сделало бы вашу жизнь намного проще (и ваши запросы быстрее).
Вы не можете решить вашу проблему с помощью предложения GROUP BY, потому что для каждой группы pid MySQL будет просто извлекать первый pid, максимальную дату и первую найденную цену (это не то, что вам нужно
Вы можете использовать подзапрос (который может быть неэффективным):
SELECT pid, date, price
FROM ProductPrice p1
WHERE date = ( SELECT MAX(p2.date)
FROM ProductPrice p2
WHERE p1.pid = p2.pid)
или просто присоединить таблицу к самой себе:
SELECT p1.pid, p1.date, p1.price
FROM ProductPrice p1
LEFT JOIN ProductPrice p2 ON p1.pid = p2.pid
AND p1.date < p2.date
WHERE p2.pid IS NULL
Взгляните на этот раздел документации MySQL.
Вы можете попробовать следующее:
SELECT pid, price, date FROM ProductPrice GROUP BY pid ORDER BY date DESC
Группа имеет некоторые непонятные функции, я тоже всегда не уверен, правильное ли это поле ... но это должно быть первым в наборе результатов.
Вот еще один - возможно, неэффективный-:
SELECT pid, substring_index( group_concat( price order by date desc ), ',', 1 ) , max(date)
FROM ProductPrice
GROUP BY pid
Я столкнулся с той же проблемой в одном из моих проектов. Я использовал подзапрос для получения даты, а затем для сравнения, но это замедляет работу системы при увеличении данных. поэтому лучше хранить последнюю цену в таблице «Товары» в дополнение к новой таблице, которую вы создали для хранения истории изменений цен.
Вы всегда можете использовать любой из предложенных запросов, чтобы получить последнюю цену продукта на конкретную дату. но также вы можете добавить одно поле в ту же таблицу, если оно самое последнее. поэтому для одного свидания вы можете сделать флаг истинным один раз. и вы всегда можете узнать последнюю цену продукта на определенную дату с помощью одного простого запроса.
Я думаю, что ключевым моментом здесь является простой звучащий запрос - вы можете видеть то, что хотите, но компьютеры не люди, и поэтому для получения желаемого результата с помощью операций на основе наборов вы должны быть явными, как во втором запросе.
Внутренний запрос определяет последнюю цену для каждого продукта, затем внешний запрос позволяет вам получить значение последней цены - это почти настолько просто, насколько это возможно.
] Кроме того, если у вас есть система выставления счетов, вам действительно следует хранить цену продукта (и налоговые ставки, а также «коды») вместе со счетом, т.е. таблицы счетов должны содержать всю необходимую финансовую информацию, чтобы воспроизвести счет-фактуру. В основном, вы не хотите полагаться на то, что сможете найти цену (или налоговую ставку) в изменяемой таблице, даже с учетом представленной выше системы. Независимо от этого у истории ценообразования есть свои достоинства.