[Opensim-dev] Search server DB schema

[Justin Clark-Casey]

Regarding database harmonization, I agree in principle that it is 
desirable to have uniformity across data representations - I believe 
much of the current situation is historical accident.  I also feel it is 
important to provide a migration path for OpenSim users with existing 
data, preferably one which is automatic - harmonization is not quite as 
simple as simply deciding on a uniform representation.  These are my own 
views and not necessarily those of other OpenSim developers.  I also 
feel that database harmonization is not currently one of our most 
pressing issues.

FYI, there are some changes currently in the works to make it easier 
than it currently is to migrate data between changing database schemas 
as OpenSim evolves.  I feel it would be sensible to wait until these are 
committed before doing any harmonization work.

Regards,

justincc


SignpostMarv Martin wrote:
> 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
>>>   
>>>     
>>>       
>>   
>>     
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>   


-- 
justincc
Justin Clark-Casey