Re: [hfdb] Re: Grand Unified Hardware Database

[Zenaan Harkness]

On Mon, 2004-07-26 at 23:55, James K. Lowden wrote:
> On Mon, 26 Jul 2004, Zenaan Harkness <address@hidden> wrote:
> > On Mon, 2004-07-26 at 09:56, James K. Lowden wrote:
> > > My idea is to define stored procedures to insert the data.  You call
> > 
> > Here's another question - do you have experience with stored procedures
> > with more than one RDBMS backend, such that you can say how "specific to
> > RDBMS backend" stored procedures can be?
> 
> I've worked mostly with Sybase and Microsoft RDBMSs.  They share a common
> heritage, and even there it's not hard to write a query that won't execute
> in both systems.  
> 
> >From reading manuals (because the question is interesting to me), it looks
> like it's impossible to write RDBMS-independent procedures, and difficult
> to write even a one-way conversion for them.  A human being can read one
> and get the gist of it, and convert it by hand, of course.  

OK, that sounds fine - something I can readily do.

> One example of a problem is that some databases have the notion of a
> "temporary table" that exists only for the process and self destructs at
> end of query.  The paradigm breaks down on systems that lack that feature.
>  ;-)

I'll look at the semantics of the each stored procedure you write, and
if it relies on the concept of a temporary table, it should be too hard
to create such a thing.

> > > 'PrintersInsert' passing it a bunch of parameters, and it does the
> > > rest, doling out various parts in the related tables that define a
> > > printer.  
> > 
> > And checking constraints? Or are constraints specified in some other
> > manner (or a combination)?
> 
> Yes.  

That'll teach me to ask three questions in one sentence; I take it you
mean any combination.

> > > I imagine your "Microsoft Natural Keyboard" to be a record in a file. 
> > > A little DBI Perl script will read the records, taking the name of the
> > > stored procedure as a parameter.  Note we need only 1 such script,
> > > because it calls any procedure with any number of parameters.  If the
> > > database rejects a record, it can note that in a log file and proceed
> > > to the next one.  
> > 
> > For me-as-end-user submitting my single keyboard record, that file will
> > be a plain text file with just the data for my keyboard - or now that I
> > write that I imagine a little more structure will need to be defined,
> > and me-as-hfdb-team-member will have to make sure that file (/email) is
> > in the "correct" format?
> 
> Someone entering a single device would want a form, probably a web form. 
> I'd suggest our CGI script append the data to a file that we subsequently
> apply to the database after vetting.  You don't want random people adding
> Bogon devices.

Hmm, Bogon device. If it's got anything to do with Teleportation, I'm
interested.

> Sure.  I'll set up a nightly export.  We have to discuss whether or not
> the export should be in CVS or managed more like rotating logs.  

CVS is the archive tool on savannah AIUI. We'll think about it more
later, but I suspect something more compact than the entire db (which
will be mostly the same one night to the next) will be desirable.

This format needs to be:
 - human readable (ie. text, not binary)
 - usable to recreate/ restore the database

cheers
zen