MySQL - IF something, THEN also select where - mysql

So, I have a confusing MySQL issue. I feel like I need to use some IF statements, but I'm really not sure how to implement them into this situation! First, consider the following query. It's simple:
SELECT *
FROM flow
INNER JOIN flow_strings
USING(node_id)
WHERE
(
flow.parent = 0
OR flow.parent = :user_flow
)
AND flow.source = 0
AND :input LIKE flow_strings.sql_regex
However, I need to expand it, and that's where I'm stuck. Thinking through this, I'm not really sure how to explain it, so following are the table structures, and then some examples.
TABLE flow
+---------+--------+--------+
| node_id | parent | source |
+---------+--------+--------+
| 1 | 0 | 0 |
+---------+--------+--------+
| 2 | 0 | 0 |
+---------+--------+--------+
| 3 | 1 | 1 |
+---------+--------+--------+
| 4 | 3 | 0 |
+---------+--------+--------+
TABLE flow_strings
+----------------+---------+-----------+
| flow_string_id | node_id | sql_regex |
+----------------+---------+-----------+
| 1 | 1 | fish |
+----------------+---------+-----------+
| 2 | 1 | wish |
+----------------+---------+-----------+
| 3 | 1 | *yes* |
+----------------+---------+-----------+
| 4 | 2 | *no* |
+----------------+---------+-----------+
| 5 | 2 | nay |
+----------------+---------+-----------+
| 6 | 3 | *herp* |
+----------------+---------+-----------+
[ ... ]
TABLE placeholder_variables
+-------------+--------+------+-------+
| variable_id | source | name | value |
+-------------+--------+------+-------+
| 1 | 0 | yes | sure |
+-------------+--------+------+-------+
| 2 | 0 | yes | yeah |
+-------------+--------+------+-------+
| 3 | 0 | no | nope |
+-------------+--------+------+-------+
| 4 | 1 | herp | derp |
+-------------+--------+------+-------+
NOW, here's what I need to happen based on :input.
"fish", "wish", "sure", or "yeah" ---SELECT flow.node_id 1
This is because "fish", "wish", and "*yes*" are all associated with flow.node_id 1. Note that *yes* is surrounded by asterisks, so instead of "yes" being interpreted literally, it instead draws the values from placeholder_variables.
"nope" or "nay" ---SELECT flow.node_id 2
This is because "*no*" and "nay" are associated with flow.node_id 2. Again, because of the asterisks, "no" is not interpreted literally, but "nope" matches because "no" is in the placeholder_variables table, even though "nope" is not in the flow_strings table.
"no" and "*no*" ---NO MATCH
Even though *no* is in flow_strings, it should not match because it has asterisks around it (and a corresponding placeholder_variable) which means it should not be interpreted literally, and so can only be evaluated by its corresponding placeholder variable's value(s).
"baby" ---NO MATCH
Even though "baby" does not have asterisks around it, it corresponds to flow.node_id 3, and that node's flow.source is 1.
"derp" ---NO MATCH
This is because placeholder_variables.source is 1 for *herp*, even though it is in the flow_strings table.
"*herp*" ---SELECT flow.node_id 4
Even though there are asterisks around *herp* in the flow_strings table, the corresponding placeholder_variable.source is 1.
** TO SUM UP **
No source = 1
Interpret placeholder_variables if the sql_regex is surrounded by asterisks, but only if the corresponding placeholder_variable's source is 0.
If source is 0, and no asterisks are present, interpret sql_regex literally.
I know that I can use MySQL's SUBSTRING() to work with the asterisks. I also know that, (as I am using PHP) I could theoretically split this into two queries, and then dynamically generate the second query by looping through the first. However, this would be both A) memory intensive, and B) sloppy.
So my question is this: Is it possible to do this using MySQL alone? If yes, how would you recommend I format it? You don't need to write the query for me, but if you could help me with some of the logic, I'd be very grateful! I have absolutely no idea what to try besides what I have already outlined, and I definitely don't want to do that.
Thanks!

You can use this solution:
SELECT a.*,
COALESCE(c.value, b.sql_regex) AS string #-- If there was a successful JOIN (sql_regex was a variable), then display the value of the "value" column in placeholder_variables, otherwise if the JOIN did not succeed (sql_regex was a literal value), just display sql_regex instead.
FROM flow a
JOIN flow_strings b ON a.node_id = b.node_id
LEFT JOIN placeholder_variables c #-- LEFT JOIN placeholder_variables on these conditions:
ON b.sql_regex LIKE '*%*' AND -- That sql_regex is a variable
REPLACE(b.sql_regex, '*', '') = c.name AND -- Match sql_regex up with the "name" column in placeholder_variables. We must replace the asterisks in sql_regex so that the values can match ("name" column do not contain asterisks)
c.source = 0
WHERE a.source = 0 AND
COALESCE(c.value, b.sql_regex) = :input -- If the string was interpreted as a placeholder variable, make the condition on the interpreted value in the placeholder_variables table ("name" column), otherwise, just make the condition on the sql_regex column.
SQLFiddle Demo

Related

Separating a comma separated string to a new table

I inherited a project that has comma separated strings stored in a field called 'subsector' in a table named 'com_barchan_project'. I need to change this horrible design, since it's proving to be an issue trying to parse through this field. See HERE for the full story:
| id | name | sector | subsector |
+----+------+--------+-----------+
| 1 | test | 2 | 3,4,7 |
+----+------+--------+-----------+
| 2 | door | 5 | 2 |
I have created a new table called 'com_barchan_project_subsector_join' with the required fields and would like to move the values stored in 'com_barchan_project' to this new empty table.
Can anyone help me with the SQL statement that would accomplish this?
Here's what the new 'com_barchan_project_subsector_join' table should look like:
| id | project_id | subsector_id |
+----+------------+--------------+
| 1 | 1 | 3 |
+----+------------+--------------+
| 2 | 1 | 4 |
+----+------------+--------------+
| 3 | 1 | 7 |
+----+------------+--------------+
| 4 | 2 | 2 |
Once I move over the data, I will remove the 'subsector' field from the 'com_barchan_project' table and be done with it.
Thanks for your help!!!
John
Using shorter table names for brevity/clarity; and assuming you have (or can easily make) a comprehensive subsectors table...and assuming your csv are stored in a consistent format (no spaces at least).
INSERT INTO `project_subsectors` (project_id, subsector_id)
SELECT p.id, s.id
FROM projects AS p
INNER JOIN subsectors AS s ON p.subsector = s.id
OR p.subsector LIKE CONCAT(s.id, ',%')
OR p.subsector LIKE CONCAT('%,', s.id, ',%')
OR p.subsector LIKE CONCAT('%,', s.id)
;
I can't guarantee it will be fast; I'd be surprised if it was.
ON FIND_IN_SET(s.id, p.subsector) > 0 may work as well, but I am not as familiar with the behavior of that function.

Mysql concatenate only specific rows

In Mysql, I have the following table:
id | paramname | paramcategory | value |
---+-------------+-------------------+-----------------+
1 | width | dimensions | 240 |
2 | height | dimensions | 400 |
3 | param1 | category1 | some value 1 |
4 | param2 | category1 | some value 2 |
5 | param3 | category10 | some value 100 |
...
I'd like to have a query that will return a table with only several rows concatenated, and all other rows should remain intact, something like this:
paramname | value |
--------------+--------------+
width, height | 240 x 400 |
param1 | some value 1 |
...
I'm thinking about concatenating based on the needed paramcategory, but if possible/needed, concatenation can happen for specific paramnames as well. Whatever is easier/simpler.
Any help please?
Looking at this problem from above, you are going to have to 'UNION' 2 queries together. The first part of the union is your concat'd results, the second your original rows. For the first part you are going to need to do a self join on this table, along the lines of
select concat(a.paramname, b.paramname), concat(a.value, b.value) from table a, table b where a.paramcategory = b.paramcategory
along those lines....
Actually if you swap the 2 parts of the union around, you'll keep the original column names too.

How to get MySQL command line tool to show booleans stored as BIT sensibly by default

I got a problem with selecting boolean types stored as BIT with MySQL. I know that I can get bit values shown in a sensible with with custom queries like with SELECT CAST(1=1 AS SIGNED INTEGER) or with SELECT BOOLFIELD + 0 ...
However, is there any way to get our booleans shown in a sensible way with command line client with queries like SELECT * FROM TABLE ?
UPDATE : At the moment I see only space in the results Example:
mysql> SELECT distinct foo, foo + 0 from table
+------+-------+
| foo | foo_0 |
+------+-------+
| | 0 | <-- Only space
| | 1 | <-- Space, one space less
+------+-------+
With some googling, I found some (maybe related) bugs from MySQL bug DB (http://bugs.mysql.com/bug.php?id=28422, http://bugs.mysql.com/bug.php?id=43670) but not answer or fix?
To store booleans, one really ought to use MySQL's BOOLEAN type (which is an alias for TINYINT(1), given that MySQL doesn't have real boolean types): 0 represents false and non-zero represents true.
Whilst it might feel like storing a boolean in a byte is more wasteful than in a BIT(1) column, one must remember that a few saved bits will translate into more bit operations for the CPU on data storage & retrieval; and I'm unsure whether most storage engines pad BIT columns to the next byte boundary anyway.
If you insist on using BIT type columns, you should be aware that they are returned as binary strings. The MySQL command line client (stupidly) attempts to render binary strings as textual (by applying its default character set), which is what causes the behaviour that you observe—there's no way to avoid this (other than to manipulate the field in the select list in order that it as returned as something other than a binary string, as you are already doing).
However, if you also insist on using SELECT * (which is bad practice, albeit somewhat more understandable from the command line client), you might consider defining a view in which the manipulation is performed and then SELECT from that. For example:
CREATE VIEW my_view AS SELECT foo + 0 AS foo, bar FROM my_table;
Then one could do:
SELECT * FROM my_view WHERE foo = 1 AND bar = 'wibble';
A BIT ugly, but maybe some workaround: CASE WHEN ... THEN ... END
Instead of
> select
guid,
consumed,
confirmed
from Account
where customerId = 'xxxx48' and name between xxxx and xxxx;
+--------------------------------------+----------+-----------+
| guid | consumed | confirmed |
+--------------------------------------+----------+-----------+
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | |
+--------------------------------------+----------+-----------+
One could do:
> select
guid,
case when consumed then '1' when not consumed then '0' end as been_consumed,
case when confirmed then '1' when not confirmed then '0' end as been_confirmed
from Account
where customerId = 'xxxx48' and name between xxxx and xxxx;
+--------------------------------------+---------------+----------------+
| guid | been_consumed | been_confirmed |
+--------------------------------------+---------------+----------------+
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 1 | 1 |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 1 | 0 |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 1 | 0 |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 1 | 1 |
| xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 1 | 0 |
+--------------------------------------+---------------+----------------+

comparing two SQL tables set cut-set to true and else to false

for my new project I decided to optimize all kind of inefficient SQL queries I've used on my older projects before importing it. After some hours on a problem that in my opinion seems to be very simple I am at a loss. I've got two different Tables that are holding user-IDs
table r table s
+-----+ +-----+
| user| | user|
+-----+ +-----+
| 2 | | 1 |
| 3 | | 4 |
| 4 | +-----+
+-----+
what I want now is to compare both Tables and setting a true or false flag in another column of the result table which shows me what value of table s is in table r. So what I want is just set the cut-set to true. the result table should look like this
result
+-----+-------+
| user| flag |
+-----+-------+
| 1 | FALSE |
+-----+-------+
| 4 | TRUE |
+-----+-------+
So the user 4 is the only user that is listed in table r. I already tried some solutions with IF clauses but I'm not pro in SQL but I do my best to get closer to that aim. My idea was this query
SELECT
r.user,
IF(r.user = s.user, TRUE, FALSE) AS flag
FROM
r,
s
I know that it isn't correct at all because the query gives me the following 6 rows.
result
+-----+-------+
| user| flag |
+-----+-------+
| 2 | 0 |
+-----+-------+
| 2 | 0 |
+-----+-------+
| 3 | 0 |
+-----+-------+
| 3 | 0 |
+-----+-------+
| 4 | 0 |
+-----+-------+
| 4 | 1 |
+-----+-------+
so the last row to each user seems to be the result I want but the problem is that the false table is combined with the flag and each user has two flags. I don't understand whats going wrong and I would be appreciated if someone could explain me how the SQL server understands my query and what I have to change to get the correct result
You have no join condition, so your query is simply creating a cartesian product between the two tables. It then reports true or false depending on whether the users match in a particular pairing. You would see this if you included s.user in your SELECT clause.
To do what you want, you should use an outer join.
SELECT s.user, r.user IS NOT NULL AS flag
FROM s
LEFT JOIN r
ON r.user = s.user
Try:
SELECT r.user FROM r,s flag WHERE r.user = s.user

need explanation for this MySQL query

I just came across this database query and wonder what exactly this query does..Please clarify ..
select * from tablename order by priority='High' DESC, priority='Medium' DESC, priority='Low" DESC;
Looks like it'll order the priority by High, Medium then Low.
Because if the order by clause was just priority DESC then it would do it alphabetical, which would give
Medium
Low
High
It basically lists all fields from the table "tablename" and ordered by priority High, Medium, Low.
So High appears first in the list, then Medium, and then finally Low
i.e.
* High
* High
* High
* Medium
* Medium
* Low
Where * is the rest of the fields in the table
Others have already explained what id does (High comes first, then Medium, then Low). I'll just add a few words about WHY that is so.
The reason is that the result of a comparison in MySQL is an integer - 1 if it's true, 0 if it's false. And you can sort by integers, so this construct works. I'm not sure this would fly on other RDBMS though.
Added: OK, a more detailed explanation. First of all, let's start with how ORDER BY works.
ORDER BY takes a comma-separated list of arguments which it evalutes for every row. Then it sorts by these arguments. So, for example, let's take the classical example:
SELECT * from MyTable ORDER BY a, b, c desc
What ORDER BY does in this case, is that it gets the full result set in memory somewhere, and for every row it evaluates the values of a, b and c. Then it sorts it all using some standard sorting algorithm (such as quicksort). When it needs to compare two rows to find out which one comes first, it first compares the values of a for both rows; if those are equal, it compares the values of b; and, if those are equal too, it finally compares the values of c. Pretty simple, right? It's what you would do too.
OK, now let's consider something trickier. Take this:
SELECT * from MyTable ORDER BY a+b, c-d
This is basically the same thing, except that before all the sorting, ORDER BY takes every row and calculates a+b and c-d and stores the results in invisible columns that it creates just for sorting. Then it just compares those values like in the previous case. In essence, ORDER BY creates a table like this:
+-------------------+-----+-----+-----+-----+-------+-------+
| Some columns here | A | B | C | D | A+B | C-D |
+-------------------+-----+-----+-----+-----+-------+-------+
| | 1 | 2 | 3 | 4 | 3 | -1 |
| | 8 | 7 | 6 | 5 | 15 | 1 |
| | ... | ... | ... | ... | ... | ... |
+-------------------+-----+-----+-----+-----+-------+-------+
And then sorts the whole thing by the last two columns, which it discards afterwards. You don't even see them it your result set.
OK, something even weirder:
SELECT * from MyTable ORDER BY CASE WHEN a=b THEN c ELSE D END
Again - before sorting is performed, ORDER BY will go through each row, calculate the value of the expression CASE WHEN a=b THEN c ELSE D END and store it in an invisible column. This expression will always evaluate to some value, or you get an exception. Then it just sorts by that column which contains simple values, not just a fancy formula.
+-------------------+-----+-----+-----+-----+-----------------------------------+
| Some columns here | A | B | C | D | CASE WHEN a=b THEN c ELSE D END |
+-------------------+-----+-----+-----+-----+-----------------------------------+
| | 1 | 2 | 3 | 4 | 4 |
| | 3 | 3 | 6 | 5 | 6 |
| | ... | ... | ... | ... | ... |
+-------------------+-----+-----+-----+-----+-----------------------------------+
Hopefully you are now comfortable with this part. If not, re-read it or ask for more examples.
Next thing is the boolean expressions. Or rather the boolean type, which for MySQL happens to be an integer. In other words SELECT 2>3 will return 0 and SELECT 2<3 will return 1. That's just it. The boolean type is an integer. And you can do integer stuff with it too. Like SELECT (2<3)+5 will return 6.
OK, now let's put all this together. Let's take your query:
select * from tablename order by priority='High' DESC, priority='Medium' DESC, priority='Low" DESC;
What happens is that ORDER BY sees a table like this:
+-------------------+----------+-----------------+-------------------+----------------+
| Some columns here | priority | priority='High' | priority='Medium' | priority='Low' |
+-------------------+----------+-----------------+-------------------+----------------+
| | Low | 0 | 0 | 1 |
| | High | 1 | 0 | 0 |
| | Medium | 0 | 1 | 0 |
| | Low | 0 | 0 | 1 |
| | High | 1 | 0 | 0 |
| | Low | 0 | 0 | 1 |
| | Medium | 0 | 1 | 0 |
| | High | 1 | 0 | 0 |
| | Medium | 0 | 1 | 0 |
| | Low | 0 | 0 | 1 |
+-------------------+----------+-----------------+-------------------+----------------+
And it then sorts by the last three invisble columns which are discarded later.
Does it make sense now?
(P.S. In reality, of course, there are no invisible columns and the whole thing is made much trickier to get good speed, using indexes if possible and other stuff. However it is much easier to understand the process like this. It's not wrong either.)