I'm going to perform a search in my SQL server DB (ASP.NET, VS2010,C#), user types a phrase and I should search this phrase in several fields, how is it possible? do we have functions such as CONTAINS() in SQL server? can I perform my search using normal queries or I should work in my queries using C# functions?
for instance I have 3 fields in my table which can contain user search phrase, is it OK to write following sql command? (for instance user search phrase is GAME)
select * from myTable where columnA='GAME' or columnB='GAME' or columnC='GAME
I have used AND between different conditions, but can I use OR? how can I search inside my table fields? if one of my fields contains the phrase GAME, how can I find it? columnA='GAME' finds only those fields that are exactly 'GAME', is it right?
I'm a bit confused about my search approach, please help me, thanks guys
OR works fine if you want at least one of the conditions to be true.
If you want to search inside your text strings you can use LIKE
select * from myTable where columnA like '%GAME%' or columnB like '%GAME%' or columnC like '%GAME%'
Note that % is the wildcard.
If you want to find everything that begins with 'GAME' you type LIKE 'GAME%', if you allow 'GAME' to be in the middle you need % in both ends.
You can use LIKE instead of equals and then it can contain wildcard characters, so your example could be:
select * from myTable where columnA LIKE '%GAME%' or columnB LIKE '%GAME%' or columnC LIKE '%GAME%'
Further information may be found in MSDN
This is going to do some pretty heavy lifting in terms of what the database has to do though - I would suggest you consider something like full text search as I think it would more likely be suited to your scenario and provide faster results (of course, if you never have many records to search LIKE would probably do fine). Information on this is also in MSDN
Don't use LIKE, as suggested by other answers. It won't work with indexes, and therefore will be slow to return and expensive to run. Instead, you have two options:
Option 1: Full-Text Indexes
do we have functions such as CONTAINS() in SQL server?
Yes! You can use the CONTAINS() function in sql server. You just have to set up a full-text index for each of the columns you need to search on.
Option 2: Lucene.Net
Lucene.Net is a popular client-side library for searching text data that integrates closely with Sql Server. You can use it to make implementing your search a little easier.
Related
I have a table in my SQL Server database which has more than 400000 rows and I want to select the full names that starts with several names that are in a .txt file approximately more than 150 name, so how would the query will be inside my command in C# .. I could write it in this way but it will be too long and may create a delay or some kind of bugs !
select *
from tableName
where fullName like '%Jack%'
or fullName like '%Wathson%'
--.... and so on
First, SQL Server can handle very long queries. I have created queries that are at least 150k characters, and they work without problem. The limit is considerably larger than that.
Second, you are correct that a bunch of like statements is going to take a long time. There is overhead to like.
Third, your patterns do not conform to your statement. If you want names that start with a particular pattern, then remove the wildcard from the beginning of the pattern. This has the added benefit that SQL Server can use a regular index on FullName for the match.
Finally, if you are really looking at initial strings, then you might want to consider a full text index (here is one place to start). These are usually more efficient than using like.
I am trying to find some views which have a comment in them - in the code! - (something like '--TO DO'), but the problem is that I don't know the views names and to look at each by hand would take me a whole lot of time (I have over 2k views).
So I am trying to make a query that will search in the view's code for the text of interest.
I managed to come up with something like this:
SELECT *
FROM ALL_SOURCE
WHERE UPPER(text) LIKE UPPER('%my_text_here%')
ORDER BY name desc
But this doesn't query my views. It queries the functions, the procedures, packages, triggers...pretty much everything except the views...which I find pretty odd.
At first I thought that maybe there were no views that contained that keyword so I changed to some basic SQL keywords that I knew for sure exist...and still no results.
Anyone could tell me what am I missing/doing wrong?
Thanks!
The views are stored in all_views (also: dba_views or user_views, depending on your access and needs). However, the text column in all_views is a long, which means you'll first have to convert it to a Clob before you can use it in your query. The easiest work around (from Tom Kyte) would be to create a new table in your schema and convert the Longs into Clobs like this:
create table myviews as
select owner, view_name, to_lob(text) as text from all_views;
Then select from your own table:
select *
from myviews
where upper(text) like upper('%my_text_here%')
order by view_name desc;
First of all before I get into the question, I'll preface this with the fact that I know that this is a "bad" idea. But for business reasons it is something that I have to come up with a solution to, and I'm hoping that someone, somewhere might have some ideas on how to go about this.
I have a SQL Server 2008 R2 table that has a "OtherProperties" column. This column contains various other, somewhat arbitrary additional pieces of information that relate to the records. There is a business need to create a UDF that we can use to query the results, for example.
SELECT *
FROM MyTable
WHERE MyUDFGetValue(myTable.OtherProperties, "LinkedOrder[0]") IS NOT NULL
This would find a record where there was an array of LinkedOrder entries that contained a value at index 0
SELECT *
FROM MyTable
WHERE MyUDFGetValue(myTable.OtherProperties, "SubOrder.OrderId") = 25
This would find a property "orderId" and use its value in a comparison.
Anyone seen an implementation of this? I've seen implementations of functions. Like this JSONParser that take the values into a table which just will not get us what we need query wise. Complexity wise, I don't want to write a full fledged JSON parser, but I can if I need to.
Not sure if this will suit your needs but I read about a CLR JSON serializer/deserializer. You can find it here, http://www.sqlservercentral.com/articles/CLR/74160/
It's been a long time since you asked your question but there is now a solution you can use - JSON Select which provides various functions for different datatypes, for example the JsonInt() function. From one of your examples (assuming OrderId is an int, if not you could use a different function):
SELECT *
FROM MyTable
WHERE dbo.JsonInt(myTable.OtherProperties, 'SubOrder.OrderId') = 25
DISCLOSURE:
I am the author of JSON Select, and as such have an interest in you using it :)
If you cannot use SQL Server 2016 with built-in JSON support, you would need to use CLR e.g. JSONselect, json4sql, or custom code such as http://www.codeproject.com/Articles/1000953/JSON-for-SQL-Server-Part, etc.
I tried to use full-text search for a table called "Business" in SQL Server 2008. Here is the statement (the search term is in Chinese).
select * from Business biz where CONTAINS(biz.*,'家具')
And then I use like statement to do the same
select * from Business where Name like '%家具%'
The full-text search returns 8 results and the like search returns 9 results which is what I expected. Does anyone know what might cause this?
I don't know the Chinese language, so I can't say for sure, but here's my best guess.
SQL Server's fulltext searching is word based, while LIKE is looking for character patterns within a string. As an example in English, a CONTAINS search for "warn" would not find the word "forewarned", but a LIKE for '%warn%' would.
I have a database table with several columns; most of them are VARCHAR(x) type columns, and some of these columns have an index on them so that I can search quickly for data inside it.
However, one of the columns is a TEXT column, because it contains a very large amount of data (23 kb of plain ascii text etc). I want to be able to search in that column (... WHERE col1 LIKE '%search string%'... ), but currently it's taking forever to perform the query. I know that the query is slow because of this column search because when I remove that criteria from the WHERE clause the query completes (what I would consider), instantaneously.
I can't add an index on this column because that option is grayed out for that column in the index builder / wizard in SQL Server Management Studio.
What are my options here, to speed up the query search in that column?
Thanks for your time...
Update
Ok, so I looked into the full text search and did all that stuff, and now I would like to run queries. However, when using "contains", it only accepts one word; what if I need an exact phrase? ... WHERE CONTAINS (col1, 'search phrase') ... throws an error.
Sorry, I'm new to SQL Server
Update 2
sorry, just figured it out; use multiple "contains" clauses instead of one clause with multiple words. Actually, this still doesn't get what I want (the exact phrase) it only makes sure that all words in the phrase are present.
Searching TEXT fields is always pretty slow. Give Full Text Search a try and see if that works better for you.
If your queries are like LIKE '%string%' (i. e. you search for a string inside a TEXT field), then you'll need a FULLTEXT index.
If you search for a substring in the beginning of the field (LIKE 'string%') and use SQL Server 2005 or higher, then you can convert your TEXT into a VARCHAR(MAX), create a computed column and index this column.
See this article in my blog for performance details:
Indexing VARCHAR(MAX)
You should be looking at using Full Text Indexing on the column.
You can do complex boolean querying in FTS; like
contains(yourcol,'"My first sting" or "my second string" and "my third string"')
Depending on your query ContainsTable or freetexttable might give better results.
If you are connecting through .Net you might want to look at A google full text search
And since nobody has already said it (maybe because it's obvious) querying LIKE '%string%' bypasses your existing indexes - so it'll run slow.
Hence - why you need to use full text indexing. (which is what Quassnoi said).
Correction - I'm sure I learnt this, and always believed it - but after some investigating it (using wildcard at the start) seems OK? My old regex queries run better with likes!