[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re Printer database
- Subject: Re Printer database
- From: Patricia M Godfrey pmgodfrey@xxxxxxxx
- Date: Sun, 14 Dec 2003 16:43:33 -0500
I wasn't going to get into this, but one must have something to think of
when shoveling one's walk, so...
If we do this, we should agree beforehand on the data and the order of
items to be submitted, so that we don't have to rekey anything. Each item
of data (a field in database lingo) should be separated from the next by
a tab; if any field is empty, there should still be the same number of
tabs. Each set of fields (a record) should be separated from the next by
a LF/CR. Suggested fields:
Printer manufacturer(HP, Epson, Brother, Apple, Lexmark, etc.)(tab)Series
name (Laserjet, deskjet, LaserWriter, etc)(tab)Model No. (II-P, Stylus
Color 800, etc.)(tab)Comments.
Now, and this is important, a basic principle of database design is that
you shouldn't really have fields in the same table that aren't related in
the same way to other fields in the same table. That means that since a
given printer might have several emulations, and therefore Printer
Control Languages (e.g., there was a Panasonic laser that could use
either PCL or Postscript), printer control languages/emulations, and
XyWrite drivers (because I might use the HP-IIP driver for the same
printer that someone else uses the HPIII driver for) should be in
separate tables from the other information. This is called normal form,
and implementing one-to-many relations. So that Panasonic printer would
have one record in the Printers table, using the structure detailed
above, and then two records in the PCLUsed table, reading:
Panasonic(tab)KXP (or whatever its model number was; I forget)(tab)PCL3
Panasonic(tab)KXP(tab)Postscript
And in the Xydriver table it would have as many records as people used
driver files:
Panasonic(tab)KXP(tab)Post35N.prn
Panasonic(tab)KXP(tab)QMSKiss.prn
Panasonic(tab)KXP(tab)HP-IIP.prn
and so on.
All these can be submitted in ASCII/XYW files, and then imported into
whatever database we decide on, so long as the same structure is
observed. Suggestions and further thoughts from other database
dabblers--or, of course, real experts--are welcome.
Patricia