Salle: i know very well.

 
Decoux: Jop008: a, b and c are tables.

Clyatt: Decoux: Another one lost in parenthesis :

Gadson: Salle: when you query is in a ruby script and it is trying to deal with many types of data like varchar, text, int, float, datetime etc then you have to find a middle way. Calling someone an idiot because he is trying to write a line of code instead of writing 100 lines makes you an idiot and him proactive. Think before you talk.

Obrian: Decoux, it might be “invalid”, but I *think* MySQL allows it. Am I wrong?

Decoux: JosephSilber: no, it does not.

Clyatt: Naftilos76: I insist it is idiotic to cast integer to char only to compare it to another integer and it is even more idiotic to do it with LIKE

Khela: So m_string_used_at is a m_string = b and c = my language?

Dickirson: Interesting. I got this from my ORM.

Decoux: JosephSilber: it’s meaningless. Ditch that sql and start over.

Decoux: JosephSilber: stop using that ORM, then

Clyatt: JosephSilber: Count the s in your sqlfiddle

Tadgerson: Salle: i think you never understood me in the first place. So cut the crap. Talk to someone else.

Boid: Http://sqlfiddle.com/#!9/c0f95f/5

Clyatt: JosephSilber: The entire query doesn’t seem sensible, but no single ORM is

Decoux: JosephSilber: WHERE SELECT . = 1 isn’t particularly elegant either

Decoux: JosephSilber: nor performant.

Clyatt: JosephSilber: That’s extremely slow way to find if something exists

Ode: Salle, it’s the closest thing. Doing a cross join across 5 tables with an ORM? I’d say this is pretty decent.

Danoff: Can obviously be optimized. But for the small dataset I use it on, it’s perfect.

Clyatt: JosephSilber: . WHERE SELECT . = 1 Imagine there are 10000000 rows matching such criteria so the server has to go through all of them to calculate the COUNT* when all you need to know if single one exist

Clyatt: Naftilos76: It is crap so fix it :

Bole: Like I said, I’m dealing with a *tiny* dataset. Maybe 100 records. It’s a joke.

Heimer: And you can’t beat this: http://i.imgur.com/AbASivy.png

Clyatt: Naftilos76: It is also common mistake made by people who don’t understand the basics of SQL and relational databases: It is meaningless to attempt writing universal SELECT statement whcih will work for everything

Decoux: Naftilos76: please remain civil

Clyatt: JosephSilber: If you insist on subqueries you can at least use WHERE EXISTS

Culbreth: Decoux: did you just see what he is saying? He never understood me in the first place and he is trying to lecture

Purrington: Salle, thanks for your help, but again: I do not care. I’m dealing with an infinitesimally small dataset.

Clyatt: JosephSilber: Not that entire query looks meaningful, but at least this will be better way

Vanhofwegen: Salle: sorry about that, just forget it

Decoux: Naftilos76: I saw. Please remain civil.

Clyatt: JosephSilber: “I’m dealing with an infinitesimally small whatever” is what most of the problems with developers begin :

Clyatt: Naftilos76: No need to say sorry. I don’t care about abbreviations so I have no idea what you were trying to say :

Decoux: Salle: it’s not very nice.

Kuechler: I disagree. Everything depends on context. But I catch your drift. Thanks.

Clyatt: Naftilos76: Please understand that when you compare integers it is waste of resources to convert them to strings first. Also it is bad practice to use x LIKE ‘foo’ when comparing column to exact values. LIKE is for wildcard matches.

Clyatt: Naftilos76: What you do “works”, but is far from reasonable. With same success you can use chainsaw to open beer bottles. It wil “work” too

Clyatt: JosephSilber: Establishing bad habits and bad practices in development used to be very good for hardware makers up to early 2000s :

Salvi: Salle: i know very well what you mean but i say AGAIN : That query is dealing with all kinds of data types. Instead of using ways to understand what kind of data type i m dealing with by using regexes or isFloat or if conditons or whatever i found this to work in all tested conditions. I told you that trying to compare non-latin chars seemed to work only with casting the data type of the column. You right in a way but you are wrong in another.