From: Alberto M. R. <da...@fi...> - 2004-02-10 01:09:14
|
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: > Giuseppe- >=20 > GUS uses Perl DBI and Java JDBC to interact with the database. >=20 > 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. >=20 > Besides that, GUS does not depend directly on DBD. >=20 > 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. >=20 > I don't think there are alot of dependencies, but, to find them we woul= d=20 > need to do some research. >=20 > Steve >=20 > 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 > >> > > > >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 Alberto M. R. D=C3=A1vila <da...@fi...> Fiocruz |