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

[Zenaan Harkness]

On Wed, 2004-07-21 at 16:54, James K. Lowden wrote:

<will get to keyboard data tomorrow - about to leave>
...
> > I would like to go through the experience of creating the tables,
> > inserting some data, then exporting that in a format that you and others
> > can import. This way we can eventually figure out the best way to
> > synchronize against each others' DBs, we won't have a single central
> > point of failure.
> 
> As far as single point of failure, yes.  We'll need to copy the data out
> to flat files and archive them somewhere, so that if I or my database
> server disappear one day, it can all be recreated.  

I have gotten in a habit (actually my laptop just died, so I'm out of it
the last week), of rsync-ing between my work directories and my backup
dir.

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.

> 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? I thought that SQL92
or whatever the standard is, made things reasonably transportable -
perhaps stored procedures and the like would be problematic - are you
using any, or rather, do you need to to enforce constraints, or can the
constraints be specified by foreign keys, non-duplicate requirements and
such (that are hopefully part of "standard" SQL)??

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 :).

> > Can you export a "script" or set of SQL statements that I can try to use
> > to create a corresponding DB in my local DB?
> 
> http://www.schemamania.org/projects/chd/chd.sql
> 
> But please don't try.  
> 
> 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. Well, I
have spent some time in SQL databases (primarily postgres) and am doing
a little more these days at work too (also postgres) - so far having set
up users and database access, tunnelling and the like for our web (and
db) guy.

> Before anyone gets up in arms about free software, please don't.  Moving a
> stable database to another platform, once, is feasible, and I'm all for

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

> 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.

> rather go with what I know until things stabilize.  When another server
> and expert appear on the scene ready willing and able to guide the
> Postgres migration, I'll be there to do my part.  

Just to give you a public assurance here - if I happen to send you a
question that is too specific to Postgres, please point me back at my
docs. I expect that need won't arise though - I have a personal interest
as well as a work interest in gettings things working smoothly.

Thanks
Zen