From: Andy Colson [mailto:andy@xxxxxxxxxxxxxxx]
Sent: Sunday, March 20, 2011 8:48 PM
Subject: Re: Database Design for Components and Interconnections
You may, or may not, want a top level table:
create table chips
(
chipid serial,
descr text
);
Yes, I see great value in a top level component table. I am not sure
how to
handle multiple instances of the same type of chip in different
services. I
think the idea is to give each instance a unique service description and
or
tag number to tell them apart. I don't want to use a description as a
differentiator as several components may contribute to, say, different
parts
of an output function.
I see 'chips' as a catalogue. I may use 2 of these, 4 of those on this
particular design. Another design might have a different mix. When a
concern comes up with a particular chip used in different designs, it
would
be handy to identify all the designs that used that chip. It would also
be
useful to keep track of different versions of that chip.
Chips have package designs, they may have pins, flats, tabs, etc. They
package they may have cooling requirements, mounting options, inventory
status, suppliers, etc. Depending upon the particular application,
package
types may be coordinated.
Yeah, maybe chip was a bad name.
-- Then we will create alternate designs for each chip
create table designs
(
did serial,
chipid integer,
compid integer
);
I did not even consider the idea of a 'design' table. This will provide
a
catalogue of implementations and a great study object. I do not know
what
compid is and I would expect to include interconnections in the design.
Design may be for a particular application, study branches, customers,
etc.
-- The list of components
create table components
(
cid serial,
descr text, -- dunno if you want this, or maybe model #....
voltage float -- dunno... maybe
);
I think this is a design component table; components used in a specific
design. Is that the intent? I would think this table should link to
the
chip catalogue.
See below
-- Each component has interconnects
create table interconnects
(
iid serial,
cid integer, -- component
input bool, -- is there a different set
--- of input and output interconnects?
pintype integer, -- dunno, something describing the connection
maxlength integer
);
Each pin might have a connection which could be in or out and it might
be
power or signal, even type(s) of signal.
Now lets create some data:
insert into chips(descr) values ('math co-processor for 80386');
-- design one has two components
insert into designs(chipid, compid) values (1, 1);
I think we want cid rather than compid above, and similaryly below. I
am
guessing that this insert automatically gets a serial key generated.
As you can see my naming convention was not very good.
And yes, a serial is an auto-inc column, if you dont specify it, it'll be
generated for you.
I have a general question. I see that you consistently use very short
abbreviations such as did and cid. I have used short, medium and long.
Short are great for inputting but I am always looking up what my
abbreviations are. This has been difficult as I have never had an
efficient
way to look them up. Medium gives me a hint as to what the meaning is
but I
often get the spelling wrong since there is no consistency in how I
shorten
names. Long names with prefixes and suffixes are easily recognized but
lengthy to input. With the write editor, auto completion might over com
some on the time consumption.
How do you manage this? Just good memory?
Regards,
ray
With simple databases I keep the names simple. When they get more complex
I name the columns more complex. I started with cid, but then changed to
compid and chipid, but, of course, forgot to change some.
You also have to worry about your users. I have a payroll database, and
I'm the only one who really writes code for it, so names are a little more
terse. I have a much bigger database, with lots of end users who are not
programmers... so I make the names much more descriptive. Most of the
time, I choose names just long enough to be unique.
Most of the problem with my layout is lack of understanding of your
terminology. Hopefully it gets my ideas across about splitting up the
tables. (You can safely assume I dont know anything about EE... cuz I
dont :-) )
-Andy
