Ответ 1

Я видел такой вывод раньше.

Это вызвано крошечной ошибкой в ​​соединении. Если я правильно помню, я решил это, вложив некоторые из моих соединений в качестве подзапросов, поэтому я добавлял каждую таблицу в существующую таблицу по соединению. Я, вероятно, перебрал микс, но он отлично работал. (ОБНОВЛЕНИЕ: Да, теперь я вижу, что это именно то, что вы делаете).

В какой-то момент в этом соединении соединение не было уникальным или способ, которым вы его организовали, не был уникальным, и поэтому SQL предоставил вам все комбинации, которые он мог бы придумать.

(Предполагая, конечно, что это не просто недостающее GROUP BY, что расстраивает вещи. Это другой источник таких проблем.)

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

ОБНОВЛЕНИЕ 1: Это действительно впечатляющий взлом или ошибка, и я не могу понять, что.

LEFT JOIN gamma_results    
ON gamma_results.usin = sample_register.usin    
AND gamma_results.istp='Cs137' 

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

Обновление 2: Учитывая, что ваше жесткое кодированное соединение должно быть близко к работе, я чувствую, что хочу, чтобы GROUP выполнялась во вложенном SELECT, когда вы используете агрегированные функции (count).

Я помню, как однажды сделал довольно сложный запрос, который, когда вы добрались до него, действительно говорил "для каждого table_a add table_b". Честно подружитесь с GROUP BY, и если это не решит вашу проблему, тогда я маленькая безобидная обезьяна.

Ответ 2

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

Поскольку у меня нет данных для скрипки, вот мое предположение:

SELECT sample_register.usin,    
     DATE_FORMAT(sample_register.doc,'%d-%m-%Y') as doc1,    
     sample_register.location,    
     sample_register.description,    
     sample_register.type,    
     sample_allocation.gamma,    
     gr.act,    
     gr.act_sd,    
     gr.mdl,    
     gr.bdl,    
     gr.count_dt,
     grK40.act  
FROM sample_register    
INNER JOIN sample_allocation    
ON sample_register.usin=sample_allocation.usin
   AND sample_allocation.gamma='Y'
LEFT JOIN (
   SELECT
       usin,
    act,    
    act_sd,    
    mdl,    
    bdl,
    count_dt,
    DATE_FORMAT(count_dt,'%d-%m-%Y') as count_dt_formatted    
   FROM gamma_results    
   WHERE istp='Cs137'
) gr
ON gr.usin = sample_register.usin
LEFT JOIN gamma_results grK40   
 ON grK40.usin = gr.usin
    AND grK40.istp='k40'
    AND grK40.count_dt = gr.count_dt
WHERE mid(sample_register.usin,3,1)='F'    
AND sample_register.doc BETWEEN '2015-01-01' AND '2015-03-31'    
   AND sample_register.category='ter'    
ORDER BY mid(sample_register.usin,3,1),    
    sample_register.doc,    
    sample_register.usin

Но это просто предположение, потому что оно выглядит очень плотно для меня.

Вы писали:

В таблице gamma_results имеется 4 записи. по две записи для 10/04/2015 и 18/04/2015.: USIN, istp, act, count_dt, но в вашем запросе вы используете act,act_sd,mdl,bdl,DATE_FORMAT(count_dt,'%d-%m-%Y') as count_dt, поэтому мы можем предположить, что у вас есть еще один столбцов: act_sd,mdl,bdl.

Под вами написано: Вывести выходные данные в следующей форме (некоторые поля, которые я удалил для удобства)

15FML002            0.00769 Y   10/04/15    00
15FML002            0.00769 Y   10/04/15    12.117

Даже если какое-либо поле удалено, какие поля здесь?

Логически это: usin,act, UNKNOWN, count_dt, UNKNOWN (равно act, когда istp='K40'). но это невозможно, потому что у вас нет такого поля в запросе запроса. Мне кажется, что результат был получен в результате какого-то другого запроса, а не того, который вы нам показываете.

Но пока это моя догадка. Приглашаем вас на любые вопросы.

Ответ 3

Каждая таблица, которую вы пишете, должна иметь PRIMARY KEY. Это жизненно важная концепция в реляционных базах данных. Пока у вас есть PRIMARY KEY в sample_register, у вас нет одного в gamma_results.

Если у вас есть первичный ключ, это прогулка в парке (относительно говоря)

Предполагая, что у вас есть следующие строки:

15FML002            0.00769 Y   10/04/15    00
15FML002            0.00769 Y   10/04/15    12.117
15FML002            0.00608 Y   18/04/15    00
15FML002            0.00608 Y   18/04/15    12.117

И если предположить, что на самом деле это дубликаты отдельных строк в вашей базе данных, назначение первичных ключей приведет к созданию нового столбца, который сделает ваши данные такими:

1          15FML002            0.00769 Y   10/04/15    00
1          15FML002            0.00769 Y   10/04/15    12.117
2          15FML002            0.00608 Y   18/04/15    00
2          15FML002            0.00608 Y   18/04/15    12.117

Это немного упрощает ваш пример, учитывая, что внутри объяснения внутри вашего вопроса вы заявили, что

Для каждого USINs существует два разных значения для istp на одном count_dt. Следовательно, на каждую дату счета будут две записи для USIN с одной для istp = 'k40', а другая для istp = cs137. Поскольку USIN и дата подсчета являются общими, я хочу отобразить их в одной строке. Затем, если в USIN указано несколько дат подсчета (например, n), тогда будут записи nx2. Но мне нужно только n строк.

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

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

Очевидно, что у вас есть отношение 1: n на USIN, которое здесь хорошо представлено, но у вас также есть соотношение 1: 2 на istp. Это не отражается в другой таблице, но вместо этого все в одной таблице, что означает, что комбинации USIN и count_dt повторяются дважды по всей таблице, когда они являются точно такими же.

Я не предлагаю, чтобы вы не могли заставить этот запрос работать. Все, что вам нужно сделать, это придерживаться GROUP BY внизу. Однако, без каких-либо указателей говорить о вашей таблице будет невероятно медленно. Даже с индексами он будет медленнее, чем нужно! Важно отметить, что без PRIMARY KEY ваша база данных SQL будет делать больше работы, чем нужно, с помощью длинного снимка.

Идеальный способ

Если вы разделите свои таблицы на две части, предоставив новую PRIMARY KEY для каждой пары USIN/count_dt, затем создайте другую таблицу, которая устанавливает ваши требования istp='k40' и istp=cs137, вам нужно будет написать одна дополнительная строка запросов в вашем уже длинном запросе, и это, вероятно, чаще всего не сэкономит вам много времени.

Вместо SELECT * FROM tableA LEFT JOIN tableB on tableA.USIN=tableB.USIN... вы должны написать:

SELECT * FROM tableA
LEFT JOIN tableB on tableA.USIN=tableB.USIN
LEFT JOIN tableX on tableB.id = tableX.tableB_id
....

Вы должны получить тот же набор данных. Если вам нужны только уникальные значения, все, что вам нужно сделать, это избавиться от второго JOIN.

Если вы не можете изменить структуру таблицы

Если по какой-либо причине вы не можете изменить структуру вашей таблицы, то альтернативой будет создание составного первичного ключа, состоящего из USIN, count_dt и istp, поскольку они должны быть уникальными и должны отображаться только в определенной комбинации один раз в таблице. Это может быстро всплыть, но должно дать вам общий смысл.

Чтобы создать различные значения с помощью этого метода, вы должны иметь составной индекс на USIN и count_dt, а затем использовать GROUP BY USIN, count_dt.

Ответ 4

@masoondreamz, я создал скрипку для возможного решения. Это - http://sqlfiddle.com/#!9/5bcae/27/0

Существенным элементом решения я был сгруппирован по дате в столбце Count_DT и добавил его в совместное условие для подзапросов. Я обрезал количество столбцов в списке, который вы показали в примере.