Re: [hfdb] Scope (Was Re: Grand Unified Hardware Database)

[James K. Lowden]

On Wed, 21 Jul 2004 Zenaan Harkness wrote:
> On Wed, 2004-07-21 at 16:54, James K. Lowden wrote:
> 
> > As far as single point of failure, yes.  We'll need to copy the data
> > out to flat files and archive them somewhere 
... 
> I really would like to think that a DB-dependant script can generate
> output on a daily basis, which could be sent to me personally, or
> whoever is interested.

I think that's a good idea.  Once we have some data in the database, of
course.  ;-)

> > As far as doing this routinely and across database technologies, no,
> > unless you're involved with hfdb as a way to learn about such things. 
> > 
> > The model will evolve.  Synchronizing evolving models between two SQL
> > dialects would soak up time we need to devote to the real problem at
> > hand.
> 
> Is there that much difference between SQL dialects? 

It's like anything else, Zen: more different the closer you get.  SQL
didn't start under ANSI control and has always been the product of big
proprietary vendors.  Their compliance with SQL-92 varies, and even
something seemingly as straightforward as CREATE TABLE isn't consistent. 
Similar enough to understand, unless you're a compiler.  With things like
stored procedures, which I consider absolutely vital to a project like
this, the syntax is all over the map.  Keeping two versions of a couple
dozen stored procedures would be a royal pain.  

> I'm quite willing to learn what's needed here - although I wouldn't
> expect most "submitters" to have to do so - just so long as we have
> regular backups between at least two of us, and that others can "plug
> in" as they desire (eg. perhaps other distros, manufacturers, whoever
> really - this is a Free database after all :).

Agreed on all points.  

> > Rather than building your own database, I'd rather suggest you get
> > FreeTDS, Perl DBD::Sybase, and sqsh.  These tools I know well, and
> > they're all you need to load the database.  
> 
> I shall look into them. I suspect your concern is that my "trying" would
> cause you more work in the way of me asking lots of questions. 

Not only your questions to me, you know.  Mine to you, because I barely
know how to spell Postgres.  We'd be spending a lot of time dinking with
the scripts that could be better used.  

I just think one database is enough.  If someone else will make a server
available via the Internet and wants to play DBA, I'm happy to do just the
design work.  

> I thought the above tools _were_ free software? (leaving aside whatever
> backend you're currently using).

Yes, the tools are free, and the database isn't.  

> > it.  As things stand, I have expertise in the aforementioned tools,
> > not to mention a working server on-line and ready to go.  I myself
> > don't want to learn psql and its associated tools while I'm designing
> > the database; I'd
> 
> I'm happy for you to be oblivious to any specifics of the db I am using
> - I will gladly go hunting through manuals, google, whatever's needed.

If you really want to do the two-database dance, OK, I won't stand in your
way, as long as it's just your development sandbox.  I don't see any need
to set up an actual database for anyone until someone's really interested
in loading it with data.  And I'm not particularly interested in writing a
data-schlepping system to synchronize the two.  (Backups are one thing,
sychronization something else.)  

Just to be clear: I'm not advocating any technology (except SQL).  I'm
offering my design expertise, and volunteering to run a public server
using tools and syntax I know.  What actually happens will be a function
of who else does what.  

Regards, 

--jkl