On Thu, Jan 7, 2016 at 7:47 AM, Sabin Iacob (iacobs AT m0n5t3r DOT info) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com><= /span> wrote:

On 01/06/2016 09:28 PM, Nic= klas Karlsson (nicklas.karl= sson17 AT gmail DOT com)
[via geda-user AT de= lorie.com] wrote:
>> On Wed, 6 Jan 2016 18:09:12 +0100
>> "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via
>> geda-user AT delorie DOT com= ]" <geda-user AT delorie DOT com<= /a>> wrote:
>>
>>> Then it come to SQL can you solve file open and save as usual?= Or do
>>> you have to make connection to some kind of database?
>> Yes. SQLite.
>>
>> https://www.sqlite.org/
>>
>> Using server/client architectured database engin like postgresql i= s IMHO
>> overkill.
>>
>> Lev
> I used SQL once to write a small database application but I used an SQ= L server and even though it works and could be done it will be rather compl= icated for ordinary use. With a simple library binding it could be worth a = try.
>
>

all right, can't stand it any more, I've been eating my word= s for a
while now: please, please, please, stop with this SQL nonsense... I know that once you find a new shiny hammer everything looks like a nail, but
schematics and PCBs are graphs at the core, and SQL databases are a
pretty bad fit for storing graphs (yes, you can shoehorn them in - see
mptt - but the results are more often than not awful); I too would like
to see a more comprehensible file format for PCB, but SQL will be
anything but comprehensible (source: used SQL extensively for the last
15 or so years as a developer and a server babysitter).

as far as file formats go, while something standard like json or
(cringe) yaml or (cringe even harder) xml would have advantages
(ubiquitous library support, easy-ish to parse and modify with awk & friends for people who are so inclined), it will degenerate into
unproductive holy wars (see previous pushes for lua as the file format,
or various bickering about which text format is best); the way I see it, the process looks like this:

* decide on data model; this is where you think hard about what you need to do, how it maps to the physical world, etc.
* decide on syntax, write formal grammar; this is where you take into
account parse-ability with standard text tools and human brains (I, for
one, am a big fan of "design for humans first, computers later")<= br> * have a parser generator generate parsers for every language you use,
generate some more as they are requested

problem solved, you get canonical parsers for all languages that are
needed and no extra layers of FFI (which can be needlessly heavy)