MySQL:: varchar = mediumint ???

[zEitEr]

MySQL:: varchar = mediumint ???

Что-то не могу понять...

почему значение varchar = mediumint

например... есть две таблицы....

... order_id (где order_id - mediumint(8)) ....
1
2
3
4


и

... order_id (где order_id - varchar(32)) ...
3fb5be8209f4fe2d2a0f599b40c433d9
4aa65793f11ac97ba213585178a5234c
46eabb1906d7ca07cdce8fe5e540b4c6
37
25

При запросе...

SELECT DISTINCT * FROM table1 AS t1, table2 AS t2 WHERE t1.order_id = t2.order_id

Выдает значения, при чем оказывается, что:

3fb5be8209f4fe2d2a0f599b40c433d9 = 3
4aa65793f11ac97ba213585178a5234c = 4
46eabb1906d7ca07cdce8fe5e540b4c6 = 46
37 = 37
25 = 25


Первые три строчки они ошибочны... но как исправить запрос, чтобы он эти строчки не выдавал?

 

[Demiurg]

привести число к строке и потом уже сравнивать.
в mysql это можно сделать с помощью concat

 

[tony2001]

не сравнивать varchar с int.

 

[zEitEr]

Автор оригинала: Demiurg
привести число к строке и потом уже сравнивать.
в mysql это можно сделать с помощью concat

Спасибо большое

Очень рад. Твой подсказка мне очень помогла.


tony2001, а не сравнивать не получается....

 

[IL78]

[mod_gadalka]некоторые order_id'ы во второй таблице очень похожи на идентификаторы сессий, а order_id'ы первой - на автоинкрементые индексы заказов, для которых эти сессии были заведены[/mod_gadalka]

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

 

[Demiurg]

IL78
order_id похожи на хеш md5

 

[IL78]

Demiurg, спасибо за поправку. Просто название поля навело на определенные ассоциации...

Лично меня очень смущают 2 вещи:
1) почему на хеш md5 похожа только часть order_id-ов второй таблицы;
2) почему поля с одинаковым именем и, по-видимому, служащие для одной цели имеют различный тип и совершенно непохожие значения?

 

[zEitEr]

Поясняю....

1) [mod_gadalka] - частично все правда...
2) Значится так... есть сайтик для диллеров... они там делают свои заказы на поставку... воот... когда человек заходит на страничку заказал одну вещь... - запись в таблицу #2 с индефикатором сессии этого пользователя... заказал еще вещь - новая запись... потом, когда человек решил, что все ему хватит, он жмет оформить заказ...и воот тогда происходить запись в таблицу #1... мол новый заказ... а в таблице #2 все записи с индефикатором сессии этого пользователя меняются на номер заказа...

Почему не меняются все? Да потому что если человек не нажал оформить заказ, то записи так и остаются с этим индефикатором сессии....

И поэтому возникала проблема при сопастовлении заказов...

З.Ы. Возможно сам алгоритм не верный... но на момент решения задачи. он мне виделся единственным!

З.З.Ы. Жду.... ваших комментариев, критики и т.д.

 

[IL78]

zEitEr, чем менять кучу записей в табл. №2, не проще ли завести в табл. №1 поле типа varchar(32) и писать туда сам идентификатор сессии? По нему и связывать таблицы...

 

[zEitEr]

Автор оригинала: IL78
zEitEr, чем менять кучу записей в табл. №2, не проще ли завести в табл. №1 поле типа varchar(32) и писать туда сам идентификатор сессии? По нему и связывать таблицы...

А что если за одну сессию... пользователь сделает не один заказ, а несколько?! Как их потом сопоставлять?

 

[IL78]

Все равно, зачем переписывать varchar числом? Можно предусмотреть дополнительное int-поле для номера заказа в табл. 1. А можно, имхо, в момент оформления заказа убивать сессию и стартовать новую - тогда связь id-ов и номеров заказа останется однозначной...

 

[zEitEr]

Да...про дополнительное поле я и не подумал. Это довольно хороший момент Спасибо за подсказку.