[Opensim-dev] Search server DB schema

[SignpostMarv Martin]

I may be able to offer my anal retentiveness for database normalisation
on this matter- I would find it helpful to have a specification for the
existing tables (way too much varchar(255) for it's own good)

Justin Clark-Casey wrote:
> 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
>>   
>>     
>
>
>