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

[James K. Lowden]

On Wed, 21 Jul 2004 Zenaan Harkness <address@hidden> wrote:
> I have a device - a "Microsoft Natural Keyboard". I'm using it right
> now. How do I add it to the database? 

That's really two questions: What data go in what tables, and how does one
move the data into said tables.  

What do you know about this keyboard?  Then let's walk through where each
piece belongs.  

> I imagine that a good place to start is for me to recreate that schema
> inside my own rdbms (in my case, I'm running PostgreSQL on my
> workstation).

I think that would be not very helpful, unless you don't have a consistent
connection to the internet.  I'm going to give you access to a server I
take care of, so you can focus on the data.  

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

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.
 

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

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

--jkl