Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Having implemented this particular feature with criteria i have to say that the most straightforward way is generating a series of ICriterion LIKE's on the fly after having split the input, using the space as a delimiter. Performance is not really bad, even on a db that had something around the million-mark entries, but since LIKE queries do not take advantage of indexes its only natural that as the data set expands the query will be less performant.</p> <p>Assumptions that can be made to increase performance preemptively are to treat tokens (the parts split by space) as the beginning only, which will result in <strong>..LIKE 'JO%'</strong> which is faster than <strong>..LIKE '%JO%'</strong>, or even to treat single character tokens differently (like your second example). In my case, because i used this in autocompleted input fields i ignored them: the user must acknowledge that he is searching JO for John and JA for Jane, J would return nothing (or to be more precise the query didn't execute).</p> <p>Afterwards i implemented this using Sql Server's Fulltext and the performance difference was impressive to say the least. As always, it depends on the size of the data set, and Fulltext indexes have a maintenance overhead, at least on 2005 that i used.</p> <p>The lucene option is not a bad choice either, its fast and not difficult to implement and it unlocks the option for smart result sets like "Did you mean John" when inputting "Jon". Also its way more manageable than Sql Server's Fulltext.</p> <p>EDIT, comment answer</p> <p>I'm just saying that i have done all 3 options above... the basic <code>LIKE</code> approach worked well but after the initial implementation i was looking for perf improvements and changed the LIKE with Sql Server's FullText option (<code>CONTAINS</code>)... Both worked in production well...</p> <p>For the query generation part, if i remember correctly, i still generated dynamically the query fragments for each token, for each column (FirstName, LastName) but full-text's are better than LIKE's in actual query execution time</p> <p>in development i changed the FullText with Lucene, and while the perf characteristics are similar to fulltext, the other aspects (development, maintenance, extensions) are way better with Lucene/NHibernate.Search. I didn't have the chance to work with Sql Server's 2008 FullText implementation, which allegedly is better than 2005's</p> <p>As a boot-note, if you don't go the LIKE way and if you want to move your application to a different datastore than Sql Server, then decoupling your fulltext queries by using Lucene/NHibernate.Search is the better solution</p>
    singulars
    1. This table or related slice is empty.
    1. POSearch full name with single input box
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJaguar
    1. USJaguar
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSearch full name with single input box
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThanks for the response, it appears your implementation is very relevant here. I'm somewhat confused by your answer though, could you post some details about the exact implementation you ended up with in the end?
      singulars
      1. PO
      1. USDanP
    2. COThanks for the additional detals, very helpful.
      singulars
      1. PO
      1. USDanP
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload