0

I m having little confusion using MySQL fulltext. I have database whose charset is set to utf-8 and collation set to utf8_unicode_ci

I have following flow of searching products. User chooses from the flow below to search any product

  • user selects product_type, enum field with value consumable/unconsumable.
  • Then selects product_nature, enum 0=>finished 1- unfinished.
  • then user selects location, varchar User may select multiple location.
  • then user specifies price ranges and so on (about 5 more selection) In search page the only thing users types is, location, price ranges. Rest all they select from combo.

My confusion is.

  1. Does my database supports FULL Text Search?
  2. What are the fields I need to index for enabling full text search.
  3. As full text is supported in varchar and text datatype field only. How to get relevant results if many fields user selects for filter is in enum
  4. I want to show exact match at top and nearly matching products depending upon the filters user selects like I described above. Does order by fulltext relevancy work here because there are many fields which are of type enum.

Edit For better understand for example

This search is for those specially who knows what to buy but doesn't know anything else. Like I need a Mobile PHone, but I don't know anything else, I just select its type(Wifi/without wifi) from combo, I then select camera (with/without), I then select other few features like this. I then specify price range I can afford, I then want phone available in store in particular location. For this I type location A, location B, location C. I want results based on either of these location. And I want to order results according to the nearest match of the search parameter specified. Exact match to nearest match, then least nearest match. Hope this helps

Can anybody throw some light on this?

Thanks

Sharmila
  • 251
  • 1
  • 3
  • 14

2 Answers2

3

  1. The documentation on the Full-Text Search Functions page states that FULLTEXT can only be used with MyISAM, however, MySQL 5.6 added support for the FULLTEXT index with InnoDB (see Section 14.2.4.12.3 on the InnoDB Table and Index page). If your table(s) are setup as MyISAM, then yes - you should have support; with InnoDB, potentially - pending on your MySQL version.

  2. To enable the full-text search, you should add a FULLTEXT index only on the fields that you're going to use the search on (no point to add it to fields you won't). A FULLTEXT index can only be applied to CHAR, VARCHAR, and TEXT column-types, so that may be a start. Your product names may be too short to worry about a FULLTEXT index (consider maybe a HASH index instead), but your product descriptions (if you have them) would be really good for it.

  3. enum data is good to index with a BTREE index, not a FULLTEXT one.

  4. Not sure; could you post an example of which fields would be queried and ordered and their data-types to give a better image as to what you need?

newfurniturey
  • 34,078
  • 9
  • 85
  • 99
  • +1 I was basically writing the same answer, but I was only at question 3 :) – Tchoupi Oct 02 '12 at 15:29
  • The confusion in your first point arises because InnoDB supports `FULLTEXT` since version 5.6. Your links to the documentation are first to v5.0 then v5.6. – eggyal Oct 02 '12 at 15:30
  • @eggyal Awesome catch, I was reading through it this morning (so it's still fresh in my head) and couldn't figure out why the documentation differed; Thanks! – newfurniturey Oct 02 '12 at 15:31
  • @newfurniturey I have edited the question with example please read it – Sharmila Oct 02 '12 at 15:48
2
  1. MySQL supports full-text on MyISAM table-types, and as of 5.6.x somewhere supports fulltext on InnoDB tables.
  2. add fulltext indexes on any fields you want to do fulltext searching on. fulltext on int/binary/float fields makes no sense, so basically any varchar/text fields you need to do fulltext searches on
  3. fulltext on an enum makes no sense, since enums are intended for exact matches only
  4. you can order fulltext results by their internal relevance score.
Community
  • 1
  • 1
Marc B
  • 340,537
  • 37
  • 382
  • 468