[Opensim-dev] Search server DB schema

[Dalien Talbot]

David,

just curious - have you played with the non-relational methods of doing the
search ?

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).

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.

Another interesting beast is sphinx - I did not test it personally, but from
what they write here:

http://www.mysqlperformanceblog.com/2007/07/23/sphinx-going-beyond-full-text-search/

It looks quite promising scalability-wise.

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.

/d




On Feb 3, 2008 7:19 PM, David Wendt JR. <dcrkid at yahoo.com> wrote:

> Hello, OpenSim developers.
>
>     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".
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>     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?
>
> From,
>     KMeist Hax
>
> ------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080204/4c13fe39/attachment-0001.html>