X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cAgg5OFhxt1XaP/YriZVX/s5R7UvglfUtRR9n5dsSbk=; b=QrdzYTmXQ7m3jDD1ZClva1EJanY0+ozcmgjyQYquTYVbd7B4wW3roi+11aLxGLI9B1 AIwLieNZ/CJtey7lQ95fkAFgjMMmujlLVBQPnJhNB4mNOdwpVvEXszA8mzk+cx6WMP8w btANcQeOh4jyNrysIku1F46mYmjYufosg4eqKMqNdKM19QE1GerP6KqymhndYagQiRvf 0uOuuw8mVvf9kyD5O24rG80DFpDiuhCIPM3jobvtA02d5Q4ZnHDNSK4anHgHox1si0P8 VXJd8UtJDpigErVfHO5H/DQEDpbptWh5EoqoKH2W8dIJ/4W/oN9lygKI20omg4N1x8HW j6Lw== MIME-Version: 1.0 X-Received: by 10.107.130.28 with SMTP id e28mr28038267iod.77.1440491081892; Tue, 25 Aug 2015 01:24:41 -0700 (PDT) In-Reply-To: <20150825022302.21819.qmail@stuge.se> References: <20150824223846 DOT 0ba61ba7 AT jive DOT levalinux DOT org> <20150825022302 DOT 21819 DOT qmail AT stuge DOT se> Date: Tue, 25 Aug 2015 10:24:41 +0200 Message-ID: Subject: Re: [geda-user] pcb file format From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a113fb7003d0797051e1e777c 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 --001a113fb7003d0797051e1e777c Content-Type: text/plain; charset=UTF-8 Thanks for the comment. I don't really see how can we can implement the that any to any object attachments with FKs. Can you make an example? I'll make the names shorter. On Tue, Aug 25, 2015 at 4:23 AM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote: > Hi, > > Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > > Here I propose the file format of the next generation of PCB. > .. > > Okay. I'm not a database architect, and you can now start throwing > > Thanks for starting to do this. I do architect databases and for > edacore I would work hard to avoid an N:N table. They aren't great. > It's better to have explicit FKs between tables. I might have a > single table which includes columns for all types of objects, and I > would have a group table with a FK parent field refering to itself. > > Please eliminate all the redundancy in your schema. pcb_object -> pcb > pcb_id -> id and so on. Otherwise queries become immensely verbose. > It looks like it is important to qualify every column, but actually > in queries if there is any ambiguity then columns can optionally be > qualified with the table name, and if there isn't any then the > redundancy is avoided. This is a matter of style, but I think an > important one for efficiency and both readability and writability of > queries down the line. > > > > I know that sqlite is yet another dependency > > It's fine, don't worry. > > > //Peter > --001a113fb7003d0797051e1e777c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comment. I don't really see how ca= n we can implement the that any to any object attachments with FKs. Can you= make an example?

I'll make the names shorter.

On Tue, Aug 25, 201= 5 at 4:23 AM, Peter Stuge (peter AT stuge DOT se= ) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
Hi,

Lev (leventelist AT gmail DOT com) [v= ia geda-user AT delorie DOT com] wrot= e:
> Here I propose the file format of the next gen= eration of PCB.
..
> Okay. I'm not a database architect, and you can n= ow start throwing

Thanks for starting to do this. I do architect databases and for
edacore I would work hard to avoid an N:N table. They aren't great.
It's better to have explicit FKs between tables. I might have a
single table which includes columns for all types of objects, and I
would have a group table with a FK parent field refering to itself.

Please eliminate all the redundancy in your schema. pcb_object -> pcb pcb_id -> id and so on. Otherwise queries become immensely verbose.
It looks like it is important to qualify every column, but actually
in queries if there is any ambiguity then columns can optionally be
qualified with the table name, and if there isn't any then the
redundancy is avoided. This is a matter of style, but I think an
important one for efficiency and both readability and writability of
queries down the line.


> I know that sqlite is yet another dependency

It's fine, don't worry.


//Peter

--001a113fb7003d0797051e1e777c--