[Gusdev-gusdev] Re: [Fwd: Porting GUS to a Open SourceDB ?]

[Steve F. <sfi...@pc...>]

Alberto-

It has been a while since we did a comparison of GUS v. chado.

Here are some things to consider, on the design level, without=20
discussing what is and what is not covered by the schema:
   - GUS has been in production for 5 years
   - GUS uses explicit foreign keys and explicit tables to model all its=20
concepts.   this strong typing makes querying and loading data more=20
manageable
   - GUS uses one-level subclassing.  For example, GeneFeature and=20
RNAFeature are explicit concepts, and both are subclasses of Feature
   - GUS comes with an application framework which includes:
         - perl and java object representation
         - a "Plugin API" that uses the GUS objects and makes it easy to=20
add data (and track it) robustly
         - a bunch of plugins that load data
         - a Web Development Kit which assists in making a website that=20
queries GUS, and provides sophisticated query tools like composing=20
Boolean queries and user query history (see www.plasmodb.org)

steve

Alberto M. R. D=C3=A1vila wrote:

>Dear All,
>
>Thanks for keeping me in the loop of this. I will forward this msg to my
>colleagues (the experts in databases) to make a decision together.
>
>I have some questions on databases for genomes: a) what do you think of
>GMOD and b) if there any level of comparison with GUS ? I am looking for
>the best choice, but seems to be not so easy... How long it could take
>to make GUS database independent or to port it to an open source source
>database ?
>
>Thanks and best regards, Alberto
>
>
>On Mon, 2004-02-09 at 16:17, Steve Fischer wrote:
> =20
>
>>Giuseppe-
>>
>>GUS uses Perl DBI and Java JDBC to interact with the database.
>>
>>I just did a quick grep of the Perl code base.   There is one place=20
>>where we use DBD.  It is in our DBAdmin toolset.   This toolset is=20
>>released with GUS, but it is not considered "standard" gus.    However,=
=20
>> it is a nice toolset which provides a web display of things like:  who=
=20
>>is using the db, what queries are running, what are the constraints on=20
>>the tables, etc.   So, it would be nice if we eventually made it DBD=20
>>independent.
>>
>>Besides that, GUS does not depend directly on DBD.
>>
>>The first step to porting GUS to other DBMSs is to identify what are th=
e=20
>>DBMS dependent parts.   One example is that GUS uses schema spaces.   I=
n=20
>>other words, tables are named:  schema.table.   I know that postgres=20
>>supports this, but when we last looked mysql did not.
>>
>>I don't think there are alot of dependencies, but, to find them we woul=
d=20
>>need to do some research.
>>
>>Steve
>>
>>Giuseppe Jurman wrote:
>>
>>   =20
>>
>>>>Thanks Elisabetta,
>>>>
>>>>An important question would be also why PostgreSQL and not MySQL, the
>>>>latter appears to be evolved well and have now a good support to
>>>>transactions via InnoDB, etc. I am very inclined to use Gmod and chad=
o
>>>>por our project, but would like to have a final check on the potentia=
l
>>>>of GUS before starting things.
>>>>  =20
>>>>
>>>>       =20
>>>>
>>>ITC-irst has started a working group for a full open source version of
>>>GUS, so to allow the substitution of the Oracle database management
>>>system for data tables and relations within GUS with an open source
>>>solution. In principle we are not oriented to the substitution
>>>of Oracle with another specific DMBS.
>>>
>>>It might be worthwhile to consider the possibility to turn DB
>>>independent the whole object-related part of GUS and then choosing the
>>>suitable DB-dedicated driver depending on the user's system. The first
>>>(heavy) step towards this option requires to check the existing code
>>>looking for the Oracle-specific SQL, and then designing an ad-hoc
>>>strategy to transform into either a DBI (better) or into a DBD (here
>>>the choice of the DBMS becomes a constraint).
>>>
>>>An important issue, for us, is how to align the DBD portions of the
>>>code along the next releases of GUS. In this view, we see the need of
>>>a DBI-DBD separation really relevant.
>>>
>>>We would like to perform the Oracle-PostgreSQL conversion in the most
>>>automated way possible. Before, the Oracle proprietary SQL code has to
>>>be somehow moved to the upper Perl Object Layer level, or to a new
>>>Perl Object Layer.
>>>
>>>Comments welcomed
>>>
>>>
>>>Giuseppe Jurman
>>>Cersare Furlanello
>>>
>>>=20
>>>
>>>     =20
>>>