SQL Server Multi Term Wildcard Search on Multiple Fields with Ranking

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
0
down vote

favorite












I've built up this search query for searching airport locations on multiple fields, but I don't particularly like the way it works in practice. Even though it is fairly cool. I'll be reverting back to the original version, however I'd like to hear people's thoughts on the approach and possible alternatives.



DECLARE @SearchText nvarchar(255)
DECLARE @SearchTerms table(Term nvarchar(255))

INSERT INTO @SearchTerms
SELECT @SearchText

INSERT INTO @SearchTerms
SELECT value FROM STRING_SPLIT(@SearchText, ' ')

;WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
INNER JOIN @SearchTerms st ON l.Name LIKE '%' + st.Term + '%'
OR l.ICAO LIKE '%' + st.Term + '%'
OR l.IATA LIKE '%' + st.Term + '%'
),
cte2 AS (
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface,
SUM(cte.StartsWithName) AS StartsWithName,
SUM(cte.StartsWithICAO) AS StartsWithICAO,
SUM(cte.StartsWithIATA) AS StartsWithIATA,
SUM(cte.NameMatch) AS NameMatch,
SUM(cte.ICAOMatch) AS ICAOMatch,
SUM(cte.IATAMatch) AS IATAMatch
FROM cte
GROUP BY cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
)
SELECT cte2.*
FROM cte2
ORDER BY cte2.StartsWithName DESC,
cte2.StartsWithICAO DESC,
cte2.StartsWithIATA DESC,
cte2.NameMatch DESC,
cte2.ICAOMatch DESC,
cte2.IATAMatch DESC,
cte2.Name ASC,
cte2.ICAO ASC,
cte2.IATA ASC


Here's the original if you're interested...



DECLARE @SearchText nvarchar(255)

WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
WHERE l.Name LIKE '%' + @SearchText + '%'
OR l.ICAO LIKE '%' + @SearchText + '%'
OR l.IATA LIKE '%' + @SearchText + '%'
)
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
FROM cte
ORDER BY cte.StartsWithName DESC,
cte.StartsWithICAO DESC,
cte.StartsWithIATA DESC,
cte.NameMatch DESC,
cte.ICAOMatch DESC,
cte.IATAMatch DESC,
cte.Name ASC,
cte.ICAO ASC,
cte.IATA ASC






share|improve this question



















  • But the original is not the same
    – paparazzo
    Feb 8 at 18:55
















up vote
0
down vote

favorite












I've built up this search query for searching airport locations on multiple fields, but I don't particularly like the way it works in practice. Even though it is fairly cool. I'll be reverting back to the original version, however I'd like to hear people's thoughts on the approach and possible alternatives.



DECLARE @SearchText nvarchar(255)
DECLARE @SearchTerms table(Term nvarchar(255))

INSERT INTO @SearchTerms
SELECT @SearchText

INSERT INTO @SearchTerms
SELECT value FROM STRING_SPLIT(@SearchText, ' ')

;WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
INNER JOIN @SearchTerms st ON l.Name LIKE '%' + st.Term + '%'
OR l.ICAO LIKE '%' + st.Term + '%'
OR l.IATA LIKE '%' + st.Term + '%'
),
cte2 AS (
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface,
SUM(cte.StartsWithName) AS StartsWithName,
SUM(cte.StartsWithICAO) AS StartsWithICAO,
SUM(cte.StartsWithIATA) AS StartsWithIATA,
SUM(cte.NameMatch) AS NameMatch,
SUM(cte.ICAOMatch) AS ICAOMatch,
SUM(cte.IATAMatch) AS IATAMatch
FROM cte
GROUP BY cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
)
SELECT cte2.*
FROM cte2
ORDER BY cte2.StartsWithName DESC,
cte2.StartsWithICAO DESC,
cte2.StartsWithIATA DESC,
cte2.NameMatch DESC,
cte2.ICAOMatch DESC,
cte2.IATAMatch DESC,
cte2.Name ASC,
cte2.ICAO ASC,
cte2.IATA ASC


Here's the original if you're interested...



DECLARE @SearchText nvarchar(255)

WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
WHERE l.Name LIKE '%' + @SearchText + '%'
OR l.ICAO LIKE '%' + @SearchText + '%'
OR l.IATA LIKE '%' + @SearchText + '%'
)
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
FROM cte
ORDER BY cte.StartsWithName DESC,
cte.StartsWithICAO DESC,
cte.StartsWithIATA DESC,
cte.NameMatch DESC,
cte.ICAOMatch DESC,
cte.IATAMatch DESC,
cte.Name ASC,
cte.ICAO ASC,
cte.IATA ASC






share|improve this question



















  • But the original is not the same
    – paparazzo
    Feb 8 at 18:55












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I've built up this search query for searching airport locations on multiple fields, but I don't particularly like the way it works in practice. Even though it is fairly cool. I'll be reverting back to the original version, however I'd like to hear people's thoughts on the approach and possible alternatives.



DECLARE @SearchText nvarchar(255)
DECLARE @SearchTerms table(Term nvarchar(255))

INSERT INTO @SearchTerms
SELECT @SearchText

INSERT INTO @SearchTerms
SELECT value FROM STRING_SPLIT(@SearchText, ' ')

;WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
INNER JOIN @SearchTerms st ON l.Name LIKE '%' + st.Term + '%'
OR l.ICAO LIKE '%' + st.Term + '%'
OR l.IATA LIKE '%' + st.Term + '%'
),
cte2 AS (
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface,
SUM(cte.StartsWithName) AS StartsWithName,
SUM(cte.StartsWithICAO) AS StartsWithICAO,
SUM(cte.StartsWithIATA) AS StartsWithIATA,
SUM(cte.NameMatch) AS NameMatch,
SUM(cte.ICAOMatch) AS ICAOMatch,
SUM(cte.IATAMatch) AS IATAMatch
FROM cte
GROUP BY cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
)
SELECT cte2.*
FROM cte2
ORDER BY cte2.StartsWithName DESC,
cte2.StartsWithICAO DESC,
cte2.StartsWithIATA DESC,
cte2.NameMatch DESC,
cte2.ICAOMatch DESC,
cte2.IATAMatch DESC,
cte2.Name ASC,
cte2.ICAO ASC,
cte2.IATA ASC


Here's the original if you're interested...



DECLARE @SearchText nvarchar(255)

WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
WHERE l.Name LIKE '%' + @SearchText + '%'
OR l.ICAO LIKE '%' + @SearchText + '%'
OR l.IATA LIKE '%' + @SearchText + '%'
)
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
FROM cte
ORDER BY cte.StartsWithName DESC,
cte.StartsWithICAO DESC,
cte.StartsWithIATA DESC,
cte.NameMatch DESC,
cte.ICAOMatch DESC,
cte.IATAMatch DESC,
cte.Name ASC,
cte.ICAO ASC,
cte.IATA ASC






share|improve this question











I've built up this search query for searching airport locations on multiple fields, but I don't particularly like the way it works in practice. Even though it is fairly cool. I'll be reverting back to the original version, however I'd like to hear people's thoughts on the approach and possible alternatives.



DECLARE @SearchText nvarchar(255)
DECLARE @SearchTerms table(Term nvarchar(255))

INSERT INTO @SearchTerms
SELECT @SearchText

INSERT INTO @SearchTerms
SELECT value FROM STRING_SPLIT(@SearchText, ' ')

;WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + st.Term + '%' THEN LEN(st.Term) ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
INNER JOIN @SearchTerms st ON l.Name LIKE '%' + st.Term + '%'
OR l.ICAO LIKE '%' + st.Term + '%'
OR l.IATA LIKE '%' + st.Term + '%'
),
cte2 AS (
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface,
SUM(cte.StartsWithName) AS StartsWithName,
SUM(cte.StartsWithICAO) AS StartsWithICAO,
SUM(cte.StartsWithIATA) AS StartsWithIATA,
SUM(cte.NameMatch) AS NameMatch,
SUM(cte.ICAOMatch) AS ICAOMatch,
SUM(cte.IATAMatch) AS IATAMatch
FROM cte
GROUP BY cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
)
SELECT cte2.*
FROM cte2
ORDER BY cte2.StartsWithName DESC,
cte2.StartsWithICAO DESC,
cte2.StartsWithIATA DESC,
cte2.NameMatch DESC,
cte2.ICAOMatch DESC,
cte2.IATAMatch DESC,
cte2.Name ASC,
cte2.ICAO ASC,
cte2.IATA ASC


Here's the original if you're interested...



DECLARE @SearchText nvarchar(255)

WITH cte AS (
SELECT LocationId,
Name,
Locality,
Country,
ICAO,
IATA,
Usage,
RunwayLength,
RunwaySurface,
CASE WHEN l.Name LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithName,
CASE WHEN l.ICAO LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithICAO,
CASE WHEN l.IATA LIKE @SearchText + '%' THEN 1 ELSE 0 END AS StartsWithIATA,
CASE WHEN l.Name LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS NameMatch,
CASE WHEN l.ICAO LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS ICAOMatch,
CASE WHEN l.IATA LIKE '%' + @SearchText + '%' THEN 1 ELSE 0 END AS IATAMatch
FROM [dbo].[Locations] l with (nolock)
WHERE l.Name LIKE '%' + @SearchText + '%'
OR l.ICAO LIKE '%' + @SearchText + '%'
OR l.IATA LIKE '%' + @SearchText + '%'
)
SELECT cte.LocationId,
cte.Name,
cte.Locality,
cte.Country,
cte.ICAO,
cte.IATA,
cte.Usage,
cte.RunwayLength,
cte.RunwaySurface
FROM cte
ORDER BY cte.StartsWithName DESC,
cte.StartsWithICAO DESC,
cte.StartsWithIATA DESC,
cte.NameMatch DESC,
cte.ICAOMatch DESC,
cte.IATAMatch DESC,
cte.Name ASC,
cte.ICAO ASC,
cte.IATA ASC








share|improve this question










share|improve this question




share|improve this question









asked Jan 9 at 14:58









James Law

200128




200128











  • But the original is not the same
    – paparazzo
    Feb 8 at 18:55
















  • But the original is not the same
    – paparazzo
    Feb 8 at 18:55















But the original is not the same
– paparazzo
Feb 8 at 18:55




But the original is not the same
– paparazzo
Feb 8 at 18:55










2 Answers
2






active

oldest

votes

















up vote
2
down vote













In this case, you should be using Full Text Search to accomplish your goal.



Try using the CONTAINS predicate as in CONTAINS ((l.Name, l.ICAO, l.IATA), @SearchText)






share|improve this answer





















  • What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
    – James Law
    Jan 10 at 12:06






  • 1




    In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
    – Devasuran
    Jan 10 at 12:58











  • @JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
    – t3chb0t
    Feb 9 at 5:40


















up vote
0
down vote













I see no purpose in this statement



INSERT INTO @SearchTerms
SELECT @SearchText


If you get duplicate terms you should limit to distinct






share|improve this answer





















  • by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
    – James Law
    Feb 9 at 9:17










  • If the full string matches then a component will match.
    – paparazzo
    Feb 9 at 9:21










  • You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
    – James Law
    Feb 9 at 9:24










Your Answer




StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
);
);
, "mathjax-editing");

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "196"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f184659%2fsql-server-multi-term-wildcard-search-on-multiple-fields-with-ranking%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













In this case, you should be using Full Text Search to accomplish your goal.



Try using the CONTAINS predicate as in CONTAINS ((l.Name, l.ICAO, l.IATA), @SearchText)






share|improve this answer





















  • What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
    – James Law
    Jan 10 at 12:06






  • 1




    In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
    – Devasuran
    Jan 10 at 12:58











  • @JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
    – t3chb0t
    Feb 9 at 5:40















up vote
2
down vote













In this case, you should be using Full Text Search to accomplish your goal.



Try using the CONTAINS predicate as in CONTAINS ((l.Name, l.ICAO, l.IATA), @SearchText)






share|improve this answer





















  • What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
    – James Law
    Jan 10 at 12:06






  • 1




    In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
    – Devasuran
    Jan 10 at 12:58











  • @JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
    – t3chb0t
    Feb 9 at 5:40













up vote
2
down vote










up vote
2
down vote









In this case, you should be using Full Text Search to accomplish your goal.



Try using the CONTAINS predicate as in CONTAINS ((l.Name, l.ICAO, l.IATA), @SearchText)






share|improve this answer













In this case, you should be using Full Text Search to accomplish your goal.



Try using the CONTAINS predicate as in CONTAINS ((l.Name, l.ICAO, l.IATA), @SearchText)







share|improve this answer













share|improve this answer



share|improve this answer











answered Jan 9 at 16:57









Devasuran

512




512











  • What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
    – James Law
    Jan 10 at 12:06






  • 1




    In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
    – Devasuran
    Jan 10 at 12:58











  • @JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
    – t3chb0t
    Feb 9 at 5:40

















  • What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
    – James Law
    Jan 10 at 12:06






  • 1




    In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
    – Devasuran
    Jan 10 at 12:58











  • @JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
    – t3chb0t
    Feb 9 at 5:40
















What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
– James Law
Jan 10 at 12:06




What advantages does using full text search give me over my existing approach? I agree it's a nicer syntax but it appears to achieve the same results?
– James Law
Jan 10 at 12:06




1




1




In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
– Devasuran
Jan 10 at 12:58





In any case, the results you expect should be same. Yes, looking at it might appear that it is all the same. However, full text search (FTS) does carry multiple benefits. They are: 1) Enables you to search by keywords (creates index based on keyword) and also enables you to search by linguistic which is similar to fuzzy search technique, 2) High performance benefit: solid performance results even if you apply in VLDB data, 3) easier to read and maintain the code base.
– Devasuran
Jan 10 at 12:58













@JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
– t3chb0t
Feb 9 at 5:40





@JamesLaw I suggest reading LIKE vs CONTAINS on SQL Server
– t3chb0t
Feb 9 at 5:40













up vote
0
down vote













I see no purpose in this statement



INSERT INTO @SearchTerms
SELECT @SearchText


If you get duplicate terms you should limit to distinct






share|improve this answer





















  • by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
    – James Law
    Feb 9 at 9:17










  • If the full string matches then a component will match.
    – paparazzo
    Feb 9 at 9:21










  • You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
    – James Law
    Feb 9 at 9:24














up vote
0
down vote













I see no purpose in this statement



INSERT INTO @SearchTerms
SELECT @SearchText


If you get duplicate terms you should limit to distinct






share|improve this answer





















  • by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
    – James Law
    Feb 9 at 9:17










  • If the full string matches then a component will match.
    – paparazzo
    Feb 9 at 9:21










  • You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
    – James Law
    Feb 9 at 9:24












up vote
0
down vote










up vote
0
down vote









I see no purpose in this statement



INSERT INTO @SearchTerms
SELECT @SearchText


If you get duplicate terms you should limit to distinct






share|improve this answer













I see no purpose in this statement



INSERT INTO @SearchTerms
SELECT @SearchText


If you get duplicate terms you should limit to distinct







share|improve this answer













share|improve this answer



share|improve this answer











answered Feb 8 at 19:02









paparazzo

4,8131730




4,8131730











  • by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
    – James Law
    Feb 9 at 9:17










  • If the full string matches then a component will match.
    – paparazzo
    Feb 9 at 9:21










  • You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
    – James Law
    Feb 9 at 9:24
















  • by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
    – James Law
    Feb 9 at 9:17










  • If the full string matches then a component will match.
    – paparazzo
    Feb 9 at 9:21










  • You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
    – James Law
    Feb 9 at 9:24















by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
– James Law
Feb 9 at 9:17




by inserting @SearchText into @SearchTerms I was looking for a match on the complete search string as well as the split components of it.
– James Law
Feb 9 at 9:17












If the full string matches then a component will match.
– paparazzo
Feb 9 at 9:21




If the full string matches then a component will match.
– paparazzo
Feb 9 at 9:21












You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
– James Law
Feb 9 at 9:24




You're right, but don't forget the query ranks results and a full string match should rank higher. I appreciate your two cents but I'm not asking for someone to pull this apart - I was asking for feedback on the approach/concept.
– James Law
Feb 9 at 9:24












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f184659%2fsql-server-multi-term-wildcard-search-on-multiple-fields-with-ranking%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

Python Lists

Aion

JavaScript Array Iteration Methods