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.