Im not sure this does justice w/o any demo but Id never plan on doing
a search like that ... the idea was that one field w/ key:value pairs
would be split and put into a searchable index via Zend_Search ...
http://framework.zend.com/manual/en/zend.search.html
The query (or report) from the index search into the db is trivial
since the pk keys are exchangeable. This is really a 2 layer
approach not using MySQL for FT indexing. Any other option gives you
way more IR functions than MySQL does. Although it would be fair to
point out that it is pluggable: ( <http://dev.mysql.com/doc/refman/
5.1/en/plugin-full-text-plugins.html> ) But still pretty new.
- Jon
On May 15, 2007, at 2:01 PM, csnyder wrote:
On 5/15/07, Jon Baer <[EMAIL PROTECTED]> wrote:
I normally include @ least one column of YAML-based data
(a misc field of sorts).
At first I thought this would work with a MySQL FULLTEXT index, but of
course it won't because the field names would be in more than 50% of
the records and would therefore be considered stopwords.
Nifty as this is, then, it only works if all querying is handled by
your application or an application using a platform that includes its
own sufficiently reliable search index. Clients who want/need to
create their own SQL queries are out of luck, or forced to use LIKE
expressions.
--
Chris Snyder
http://chxo.com/
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
