X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Thu, 27 Aug 2015 14:30:56 +0200
From: "Stephen R. van den Berg (srb AT cuci DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: "Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] pcb file format
Message-ID: <20150827123056.GA8319@cuci.nl>
References: <20150824223846 DOT 0ba61ba7 AT jive DOT levalinux DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150824223846.0ba61ba7@jive.levalinux.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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.