Помогите диагностировать поведение запросов MySQL bizzare

0

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

В этом запросе участвуют 4 таблицы.

Transaction_Type
Transaction_ID (первичный)
TRANSACTION_AMOUNT
Transaction_Type

Транзакция
Transaction_ID (первичный)
Отметка

Покупка
TRANSACTION_ID
ITEM_ID

Item
iTEM_ID
CLIENT_ID

Допустим, есть транзакция, в которой кто-то платит $20 наличными и $0 в кредит он вставляет две строки в таблицу.

//row 1
Transaction_ID: 1
Transaction_amount: 20.00
Transaction_type: cash
//row 2
Transaction_ID: 1
Transaction_amount: 0.00
Transaction_type: credit

вот конкретный запрос:

SELECT 
 tt.Transaction_Amount, tt.Transaction_ID
FROM 
 ItemTracker_dbo.Transaction_Type tt
JOIN 
 ItemTracker_dbo.Transaction t
   ON
 tt.Transaction_ID = t.Transaction_ID
JOIN
 ItemTracker_dbo.Purchase p
   ON
 p.Transaction_ID = tt.Transaction_ID
JOIN
 ItemTracker_dbo.Item i
   ON
 i.Item_ID = p.Item_ID
WHERE
 t.TimeStamp >= "2010-01-06 00:00:00" AND t.TimeStamp <= "2010-01-06 23:59:59"
   AND
 tt.Transaction_Format IN ('cash', 'credit')
   AND
 i.Client_ID = 3

, когда я выполняю этот запрос, он возвращает 4 строки для конкретной транзакции. (это должно быть 2)

Когда я удаляю ALL where clauses и вставляю WHERE tt.Transaction_ID = problematicID, он возвращает только два.

ИЗМЕНИТЬ:::
 все еще повторяется при изменении диапазона дат    Кикер:

Когда я меняю начальный параметр, он возвращает только две строки для этой конкретной транзакции_имя.
::

Я использую это соединение? что все, что я могу придумать...

РЕДАКТИРОВАТЬ: Это проблема

при покупке - у двух sepparate buy_ID может быть один и тот же идентификатор транзакции (purhcase_ID разбивает продажи отдельных элементов).

Имеются повторяющиеся строки Transaction_ID в buy_ID

  • 0
    Вам нужно разместить больше информации. Для начала было бы полезно, если бы вы опубликовали 4-строчный результат, полученный по вашему запросу, который вы считаете неверным.
  • 0
    Это типичная проблема «Выбор не нарушен» ( lingpipe-blog.com/2007/06/27/… ) :)
Показать ещё 1 комментарий
Теги:

2 ответа

1
Лучший ответ

Нам нужно увидеть все данные во всех таблицах, чтобы узнать, где проблема. Тем не менее, поскольку проблемы с соединением возникают из-за того, что одна из ваших таблиц имеет две строки, если вы считаете, что она имеет только одну.

  • 0
    Спасибо - в таблице покупок есть повторяющиеся строки Transaction_ID. Вот как это должно быть. Мне просто нужно придумать другое средство, чтобы выбрать client_ID
0

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

  • 0
    Первичные ключи не должны быть уникальными.
  • 0
    Он ожидает, что вернутся два ряда. Это 4 строки, которые ему не нравятся.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню