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

[James K. Lowden]

On Mon, 26 Jul 2004 09:58:21 +1000, Zenaan Harkness <address@hidden>
wrote:
> On Mon, 2004-07-26 at 09:03, James K. Lowden wrote:
>>
> > 
> > Right.  A device isn't a bus or a connector.  It *has* those things. 
> > Else how would one store a printer with a parallel and USB port?  
> 
> Well, if they really were devices, we could have a device-device mapping
> table. In fact, some printers from memory have "smart card" readers and
> cards as "part of them", so this might not be an entirely theoretical
> example. But let's wait till we have actual data.

Interesting.  Agreed, we should wait for the data.  

> Do you have an example of where a table would want to link (foreign key)
> to a completely arbitrary device?

Sure.  Modules.DeviceID, DeviceConnectors.DeviceID.  To name two.  :-)

> > A nullable column is just an optional relationship embedded in the
> > table. To eliminate it, one need only place the column in a separate
> > table having the same key, and populate that table with only the
> > non-null values. Extant technology won't make you happy when you do
> > that, however,
> 
> Why? I'd like to understand this one, if it's easy enough to describe.

Assume table X with primary key K and attributes A and B.  B is optional
because sometimes it doesn't apply, say the phone number of the kids'
pediatrician.  We can have a table K-A-B where B is nullable.  Or we can
have a table K-A for everyone and K-B for people with kids (and
pediatricians).  K has the same structure in both tables, and the set of K
rows in K-A is a superset of those in K-B.  In K-B, B is not null, because
any row that would have a null B is simply absent: K-B has an *optional*
relationship to K-A.  

Relational theory says you represent optional relationships in separate
tables and disallow nulls.  That makes for a lot of joins that, in
practice, often performs poorly.  Hence nulls.  

> However for storage, version control, etc, it should be easy to generate
> XML from the db. WRT Till's linuxprinting database, it will make most
> sense to auto-import the data, assuming it is already in a reasonably
> standard format. As mentioned above though, we must maintain continuity
> for existing users of that data by being able to re-generate the
> format(s) they are using. So that's kind of like a precondition to
> incorporating an external set of data I guess - we must be able to
> readily export back to the currently used formats.

This is an interesting problem.  I agree, if we're to be useful to
linuxprinting, it has to be possible to produce their files.  We could
create round-trip processing: read their files, store in database,
regenerate their files.  I'm not sure that's where we should focus our
attention.  It depends if their files are the canonical source of
information.  That is, if we're going to incorporate other information
about printing that they'll want, then we'll stand to enhance their data. 
In that case, we wouldn't necessarily ever re-load from their files,
although they'd want us to regenerate them (from the combined data).  

Generating their XML might be a combined effort.  We'd write the initial
query and Perl script to generate the file.  They'd maintain the script as
their needs change, and we'd update as the schema changes.  

You asked elsewhere about the ease of XML generation from an SQL query
output.  I've done some HTML-from-SQL work (as has half the www, if PHP
and cgi scripts are any guide).  It's not hard.  If the XML tags directly
correspond to the column names in the database, it seems to me it should
be possible to write a generalized SQL-to-XML formatter.  In fact, I'd be
surprised if that hasn't been done already.  Once we're that far, we'd
need some XSLT expertise to transform the "standard" XML into the desired
form.  

> I think you're right. XML schema, SQL schema, the data issues will be
> the same - either we will address them properly, or we'll address them
> properly :)

Ultimately, those are the choices, yes.  ;-)

--jkl