Re: gEDA-user: Fwd: Parts DB API: the story so far

["Steven Michalske" <smichalske@xxxxxxxxx>]

one word,  SQLite

I know a few OSX based applications that use SQLite as a back end that
users never have to even know about, (Aperture)  it just does its own
thing.

what a data base gets you is speed of access to information and a way
to relate different type of information.

as for which database to use....  think of this as a DBI type issue.
as long as we write the interface with the ability to plug in
different database formats,  yes even including a backend that goes
through flat files  we won't have to worry about the user base that
could care less about the DB backend.  Now as a corporate user that is
working on expanding the usage of this fine package in the business  a
database backend that ran on oracle would be great.  we have some nice
large oracle servers.  my choice for home would be mySQL

and it looks like Stuart would want none of the data base solutions,
sorry to inform you,  we have a flat file database that is in woeful
disrepair and poor relational construction.  AN we loose potential
users to this fact,  as many say that they don't choose up because of
our library.

With myself coming from a large company, I know that you don't use
built in libraries but have an employee that is responsible for adding
a part you want to your part library  and including all the heavy
information into the multiple databases that are managed for
production.

Steve


On Dec 20, 2007 1:14 PM, Stuart Brorson <sdb@xxxxxxxxxx> wrote:
> > Trying to make the database optional even after developing its use
> > sounds hard.  Is there opposition to a database?  No database ever would
> > be limiting...
>
> I've been watching this discussion for quite a while.  I don't want to
> derail it, since it's good to have an exchange of ideas.  However,
> since you asked, I'll chime in.
>
> I am completely, utterly, and deadly opposed to a database, except as
> an optional plug-in -- i.e. a separate facility which the remainder of
> gEDA can run without.  If gEDA requires a database for use, then we
> lose 99% of all gEDA users.  A database is a PITA to install, build,
> maintain, administer, upgrade, and use.  It is also a dependency which
> will make gEDA uninstallable by almost everybody.
>
> The beauty of gEDA is that it is (barely) simple enough that rank
> amateurs can figure it out and produce boards.  It is also powerful
> enough that professionals can produce low to mid-level complexity
> boards.  Don't break that feature!
>
> My strongly held opinion is that if somebody wants a database for use
> with gEDA, what they *really* want is an ERP system (e.g. Sugar or
> something like that).  In that case, they are in a different class of
> gEDA user than gEDA's target audience of students, educators, hobbiests,
> etc.  Power users should consider paying for professional IT services
> to put an ERP system into place, and integrate it with gEDA.  Indeed,
> this represents a business opportunity which somebody should grab.
>
> However, gEDA should continue to operate on principles of easy
> installation, easy use, and easy maintainence.
>
> Just MHO,
>
> Stuart
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user