[BioSQL-l] Oracle support...

Hilmar Lapp hlapp at gnf.org
Tue Jul 29 17:53:27 EDT 2003


On Tuesday, July 29, 2003, at 04:03  PM, Len Trigg wrote:

> Hilmar Lapp wrote:
>> This is old and does not apply anymore. There are too many differences
>> between the RDBMSs, mysql is far too little expressive, and the
>> transform script just gave too much grief. We concluded that the rate
>> of change wouldn't be that high anymore so that it is easily 
>> affordable
>> to have RDBMS versions decoupled.
>
> OK, I guess the README should be updated then. Would you like me to
> have a crack and send you a patch?

Sure, you'd be welcome to do so.


>
>
>>> What exactly does the oracle schema do that is not satisfied by the
>>> mysql-port schema? There must be a lot of extra functionality,
>
> You did not answer this question, but I would like to know if I am
> going to be caught out later on. What functionality am I missing out
> on by using the simple mysql-port rather than the oracle schema?
>

It's primarily the following things:

	- customizable, very modular instantiation (see BS-create-all and 
BS-defs-local)

	- complete API both for SELECTs as views and for programming as PL/SQL 
packages for all tables, see also general user programming API as 
exposed in the SGAPI package (which just delegates into the table APIs)

	- load API using denormalized view with insert triggers (only on a few 
entities, and if you won't ever insert anything through sql*plus you're 
not going to hit this)

	- ready-to-use scripts for allocating staged permission levels to 
different roles

	- warehouse views with maintenance scripts, so far for genome mappings 
and accession/name/symbol searching

	- ready-to-use scripts for generating context indexes (basically, 
Oracle's text search engine) on descriptions, references, and 
function-related annotation

	- coming: gene expression warehouse table

and whatever else we're going to develop for our Symgene platform.

>
>> It won't be auto-generated though, and doesn't have to be.
>
> Does that mean you think having a low-complexity alternative oracle
> schema is worthwhile?

Sure, that's why it's very modular. The present one can be as low in 
complexity as you can go already, it's maybe just not very well 
documented how to do that. You can customize the build script to 
comment out everything except BS-DDL.sql (and you'd still be able to 
instantiate the biosql API on top of it). I don't think you can go less 
complexity than that ... (BS-DDL is just tables, indexes, FKs, 
sequences, and triggers to auto-generate the primary key)

An optional complete map to the biosql names (where possible) would 
minimize naming problems then, except for those that cannot be 
eliminated.

	-hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------




More information about the BioSQL-l mailing list