I want to use MySQL MATCH AGAINST to search various columns in a table. One of them is the email address field. Now I'm getting results that I really don't understand.
For example, I want to search for every records that holds 'domain.com' in the email address. So with a LIKE, I would do:
SELECT * FROM account WHERE email LIKE '%domain.com%'
With the MATCH AGAINST I woud do
SELECT * FROM account WHERE MATCH(email) AGAINST ('*domain.com*' IN BOOLEAN MODE)
But this returns a lot of crap which is absolutely not has anything to do with 'domain.com'. What am I doing wrong?
Note! I do a match against on several columns, email is just one of it. But this one fails terribly!
Related
I currently have an SQL table listing all the different conversations between the users of a messaging app. This table contains a column titled participantIDs which contains the user ID of each of the (two) parties in the conversation. These values are separated by a comma, for example 19,25 would denote that the conversation was between user 19 and user 25.
Now, I am trying to work out how to retrieve the relevant conversations when a user looks at their messages inbox. To do this, I expect I will need to use a line of code such as
SELECT * FROM `convos` WHERE `participantIDs` LIKE (*contains user id*);
What would be the correct way to write this query?
instead of having one column separated by a coma ,i am suggesting you a simple way, you could create a table called "Personne" with a schema (id, idSender, idRecipient, messages) , and to select all message bbetween perssonne 1 and perssone 2 , you use this request
select messages from Personne where idSender = '1' and idRecipient = '2';
in this way you will respect the first normal form as explicated here Normalization of Database
This is a really, really bad way to do it. As a.slimane says, normalize your database!...
The gist of it is that:
select messages from Personne where idSender = '1' and idRecipient = '2';
...will be fast, since you will create an index on (idSender, idRecipient) which will allow to find the rows with a direct index lookup.
However, there is no way to index a search on "part of a column contains a value". This means MySQL will have to scan many rows (potentially the whole table if you really insist) and it will be terribly slow.
Well, there is one way to index search on "part of a column contains a value": FULLTEXT. But this does not apply here.
I'm working with another programmer with a very long list of emails. He sent them to me encrypted, and said I simply need to use aes_decrypt(email, 'passwordsalt') to get them.
I used:
SELECT * FROM mydatabase.emails;
to confirm that i could see the emails (encrypted) in a table. I could. The table consists of three columns: id,email,blank.
However, when I used:
SELECT id, AES_DECRYPT(email,'passwordsalt') AS email, blank FROM mydatabase.emails;
In the column for email all I got was null values. Does anyone know if there is something wrong with my code?
I will simplify my problem in order to explain it.
I have a table which contains text messages posted by users and another table which contains keywords.
I want to display, for each user, the number of times keywords are found in text messages.
I don't want the result to display a keyword if it's not found in text messages.
I wan't it to be case INSENSITIVE. All keywords are lowered but in messages, you can find lower & upper chars.
Because I'm not sure that my explanation is clear enough, here comes the SQLFiddle.
http://sqlfiddle.com/#!2/c402a
Hope anyone can help me.
I found what I was looking for. It wasn't easy for me but here is my query :
SELECT t_msg.msg_usr,
t_list.list_word,
count(t_list.list_word),
t_msg.msg_text
FROM t_msg
INNER JOIN t_list
ON LOWER(t_msg.msg_text) LIKE CONCAT("%", t_list.list_word, "%")
GROUP BY t_msg.msg_usr, t_list.list_word;
The SQLFiddle is there : http://sqlfiddle.com/#!2/ba052/8
The recommendation would be to not try solving this with a query. It's possible to write a query that will do it, such query will scan the messages table for each keyword separately, and produce a count (or a row that you can group by), but this won't scale, or be reliable in sense of language search.
Here is what you might want to do:
Create a table to map (user_id, keyword_id) to a count of this keyword in messages of this user. Let's call it t_keyword_count.
Each time you receive a message, before you save the message into the database, search it for all the keywords you care about (using whatever good text search libraries that account for misspellings, etc.). You should know the (user_id) for this message.
You will, at that point, be ready to add the message to the database, and will have an array of (keyword_id) with keywords that this message will have.
In a transaction, insert the message into the t_msg table, and run update/insert for (user_id,keyword_id) to have value=value+1 (or +n, if you need to count the same keyword more than once in the same message) for the t_keyword_count table.
If you are trying to solve the problem of having to do the above on existing data, you can do this manually, just to build up that t_keyword_count table first (depends on how many keywords you have in total, but even if there are a lot, this can be scripted). But you should change (or mirror) the t_msg.msg_text field to be a field suitable for text search, and use SQL text search functionality to find the keywords.
i am creating a search functionality for a website where i need to take the user's full address from an input e.g "Address 32, City,Region,Country, Postal Code"(no necessary with this order) and return the available restaurant that are around the area.
I have a table "address" where there is a field for each of the above elements.
I was thinking of concatenating the users address from the database and compare it with the user's input by help of SQL REGEXP.
Is there any other approximate SQL search that can give me that or can you suggest me a different approach?
A friend suggested using (http://www.simonemms.com/2011/02/08/codeigniter-solr/) however with a small research on it the problem still remains.
Trouble with concatentating the address together in SQL is you will miss out on it using indexes. Hence it will be slow. Added to which if you do not know the order of the input elements the chances of it matching what is concatenated from the database (is a likely different order) is slim.
I would suggest for much of the address items, split them off into different tables (ie a table of regions, another of countries, etc) and just store the ids in the columns in the users table.
For a search, identify which of the search fields go with which actual field then join on those to find the real address.
Also means you can identify typos more easily.
I have a table for some companies that may have many branches in different countries. These countries are inserted in countries field.
Now, I have to make a searching system that allows users to find companies that have any branch in a specific country.
My question is: Which one do I have to use ? MATCH AGAINST or LIKE ? The query must search all records to find complete matched items.
attention: Records may have different country name separated with a comma.
MATCH AGAINST clause is used in Full Text Search.
for this you need to create a full text index on search column countries.
full text index search is much faster than LIKE '%country%' serach.
I would change the implementation: having a field that contains multiple values is a bad idea, for example, it's difficult to maintain - how will you implement remove a country from a company ?.
I believe that a better approach would be to have a separate table companies_countries which will have two columns: company_id and country_id, and could have multiple lines per company.
You should use LIKE . Because as #Omesh mentioned MATCH AGAINST clause is used for Full Text Search.. And Full Text Search need entire column for search.