Re: Proposed: Ghijk

["Sergey I. Panov" <sipan mit edu>]

 Patrick Narkinsky:
> 	1) Display Component: The display component will provide
> 	   facilities to display data in an "end-user" fashion.  
> 	   A report generater will also be included in the component.

  Is it something what one would call DB browser/viewer. As I
understand it is not going to be frequently used application. But
specialized frontends, like address book, publication references ,or
financial information, will be in use all the time.

> 	2) The Data Abstraction Layer: The data abstraction layer will
> 	   encapsulate ODBC drivers in a convenient object form.  It might 
> 	   be worthwhile to take a look at the MFC ODBC widgets
> 	   for ideas here.  Initially, this will simply be a set of object
> 	   files in the executable -- however, eventually it should be
> 	   possible to provide these services via CORBA.  This can provide
> 	   for the Database access needs of other GNOME applications.
> 	   Note: I'd say do this from the start, but I'm not sure that
> 	   the GNOME Object model is defined enough yet to know what
> 	   to implement.

Why ODBC? I personally have no experience with it, but my close
friend, who is [high ranking/highly knowledgeable] Oracle consultant,
made me think that vendor independent database solution of any type is
a trap. My understanding is that tables from one data base can not be
transfered in to another DB in 100% of cases without loss.(He had an
example when company tried to move its data from Sybase to Oracle via
ODBC and almost failed with catastrofic results). Wouldn'y it be
better to use CORBA in this project as well. In this case you would
have DB objects, one per particular DB. They needn't have the same
interface, only minimal core services would be standart to guarantee
minimal functionality. As a result, instead of one interface
(e.g. ODBC) playing role of common denominator, you will get hierarchy
of DB objects with simplest posible DB object in the root of it.

 Sergey