David,<br><br>just curious - have you played with the non-relational methods of doing the search ? <br><br>I've had a very good success with Xapian library - and it has bindings for anything and everything (although - yick. this would mean one more native code lib in the code base).<br>
<br>But the upside is that it would allow for more flexible "google-like" searches, imho - which is the very big plus. And you can allow quite a few custom tags to be included into boolean search - even though it is not very fast to index, the convenience of working with it was extremely pleasing.<br>
<br>Another interesting beast is sphinx - I did not test it personally, but from what they write here:<br><br><a href="http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text-search/">http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text-search/</a><br>
<br>It looks quite promising scalability-wise. <br><br>An engine which was theoretically very good (at least according to the benchmarks that I've read) was zettair. However, playing with the code showed the quality of it is really "alpha" - sprinkled with assert's - and not without a few bugs too :-) - so probably more of theoretical interest.<br>
<br>/d<br><br><br><br><br><div class="gmail_quote">On Feb 3, 2008 7:19 PM, David Wendt JR. <<a href="mailto:dcrkid@yahoo.com">dcrkid@yahoo.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div>Hello, OpenSim developers.<br><br> I have recently taken up OpenSim development. I'm writing plugins to allow Search to work. I need your opinion on a database schema for storing the indexed search information for a hypothetical (so far) new grid service "SearchServer".<br>
<br> I figure out for searching "Places", "Popular Places", and "Land Sales" we will need the following fields: Parcel UUID, Name, Description, LandArea, Traffic, Region UUID, Region Maturity Flag, Region Parent Estate ID, Loc X, Loc Y, Loc Z, Image UUID, ForSaleStatus, Category, ForSalePrice, AuctionID, Owner UUID, OwnerIsGroup Flag. Some of these fields won't be implemented for a long time (especially ParentEstates) but it's good to have those anyway.<br>
<br> The
"Classifieds" search tab requires these fields: Entry UUID, Name, Description, Publisher UUID, Publisher Parent Estate ID, Image UUID, ClassifiedPrice, AutoRenewFlag, Category, Region UUID, Loc X, Loc Y, Loc Z, MatureFlag.<br>
<br> The "Events" calendar search tab requires these fields: Event UUID, Name, Description, Publisher UUID, Publisher Parent Estate ID, Mature Content Flag, Event Date, Event Length, Region UUID, Loc X, Loc Y, Loc Z, Cover Charge. The Event calendar also supports notifying people who opt-in, so it would also require another table with Event UUID and Subscribing Avatar UUID.<br>
<br> New Search (which I don't forsee being able to implement until way later) also requires sim object data. Object UUID, Parent Parcel UUID, Name, ForSaleStatus, ForSalePrice, Loc X, Loc Y, Loc Z seem to be good enough.<br>
<br> Now I need your opinion on this schema. Is it a good idea to have each type
of searchable object in a separate table? Or would it be more feasible to have all the relevant fields in a single table "search" with an "objecttype" enum to differentiate between the types?<br><br>
From,<br> KMeist Hax<br></div></div><div class="WgoR0d"><br>
<hr size="1">Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target="_blank"> Try it now.</a></div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>