[Opensim-dev] Search server DB schema

Justin Clark-Casey jjustincc at googlemail.com
Mon Feb 4 08:29:26 UTC 2008


Hi David,

Personally, my instinct would be to have one table to hold all the 
common fields between these searchable objects, and separate tables to 
hold the details specific to each.

However, this opinion is formed more by my desire for neatness (not 
having lots of redundant attributes for search objects where certain 
fields don't apply) than any knowledge about how this may affect 
performance.

Regards,

--
justincc

David Wendt JR. 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%20> 
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   


-- 
justincc
Justin Clark-Casey




More information about the Opensim-dev mailing list