Mail Archives: geda-user/2015/08/27/08:32:02
Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
>So I started to write the scheme of the database, then I found myself in
>defining a complete database structure for PCB data.
>Here I propose the file format of the next generation of PCB. The file is an
>sqlite database. This is not uncommon in EDA; Zucken's CR5000 product has its
>file format as a database.
>Take a look at tree.txt. You can define primitive object, that is oval,
>rectangle, etc, and you can define pcb, and component objects. There is
>one table that lets you attach (many to many relation) objects to each
>other. There are relations, that doesn't make any sense, i.e. attaching
>a pcb object to a primitive object.
I've been toying with this idea for the past two months too.
Even started out to create a cursory schema which should work equally
well for all gschem data, as well as all pcb data.
But instead of doing it in sqlite, I'd suggest PostgreSQL instead because
of the superior recursive SQL constructs/functions and (most important
for DRC and interactive trace moving) GiST geometric indices to speed up
handling of geometric structures.
The geda/pcb schema which might be able to fit everything is this:
CREATE TABLE operator (
opid SMALLSERIAL NOT NULL PRIMARY KEY,
name TEXT NOT NULL UNIQUE
);
CREATE TABLE name (
nid SERIAL NOT NULL PRIMARY KEY,
name TEXT NOT NULL UNIQUE
);
CREATE TABLE object (
objid SERIAL NOT NULL PRIMARY KEY,
nid INT REFERENCES name ON UPDATE CASCADE
DEFERRABLE INITIALLY DEFERRED,
val TEXT
);
CREATE TABLE relation (
pobjid INT NOT NULL REFERENCES object ON UPDATE CASCADE
ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
objid INT NOT NULL REFERENCES object ON UPDATE CASCADE
ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED,
opid SMALLINT REFERENCES operator ON UPDATE CASCADE
DEFERRABLE INITIALLY DEFERRED,
loc POINT
rot FLOAT
PRIMARY KEY (pobjid,objid)
);
GiST indices are yet to be added.
The relation table supports operators to indicate different types of
relationships (additive, substractive, etc.), this works for geometric
shapes as well as for attributes.
It should easily be possible to have the applications display realtime
from the db without creating complicated extra internal datastructures.
--
Stephen.
- Raw text -