[cad-linux] Re: database cad system

G'Day !

If you are going to use a SQL database I would think in terms of 
portability.  If you write your app for MySQL, but your customer is 
using Oracle, will the app need a complete rewrite, or our you using 
industry standard libraries ?  Or do you require your customer to 
install and maintain a new database system.  If the latter, why bother 
with the database in the first place ?

That is why GtkCAD is using embedded SQL with PostgreSQL.   Embedded 
SQL is an ANSI standard, and supported by all major commerical database 
vendors.

Transaction processing is great, but really only neccessary for really 
heavy transactions loads (think airline ticketing or financial 
institutions) that I can not imagine a CAD system would generate. 
GtkCAD does almost everthing in RAM, between DB updates.  It is why 
MySQL's speed was so popular with web developers, they did not need 
transaction processing to update a web page, but speed was very 
important.  I think CAD lies somewhere in between the two.

AFAIK Triggers and such are implimented differently by every vendor.  
To take advantage of them you would need to maintain seperate trigger 
routines for every DB supported.

cheers,
Jim Parker


On 2003.06.24 09:23 Guy Edwards wrote:
> On Tue, 2003-06-24 at 12:08, Thomas Schmidt wrote:
> [snip]
> > The most popular open source database servers are mysql and
> postgresql.
> > mysql is fast as hell, but it does not have support for transactions
> and =
> > reasonable locking.
> > Unless you want a single use/single process system, mysql is a bad
> choice=
> >  for your project.=20
> 
> Hope you don't mind me just posting the other side of this (I'm not a
> MySQL expert but I've used it a bit):
> 
> For one, I thought the latest versions of MySQL (4.0+) did
> transactions.
> Admittedly I've not used transactions but I quick through their latest
> docs seems to say they do, the older versions having a workaround
> which
> they discuss:
> http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html#ANSI_diff_Transactions
> 
> Also what they have to say about locking
> http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html#MySQL-PostgreSQL_features
> 
> --copied 'n pasted---
> Table locking, as used by the non-transactional MyISAM tables, is in
> many cases faster than page locks, row locks, or versioning. The
> drawback, however, is that if one doesn't take into account how table
> locks work, a single long-running query can block a table for updates
> for a long time. This can usually be avoided when designing the
> application. If not, one can always switch the trouble table to use
> one
> of the transactional table types. See section 5.3.2 Table Locking
> Issues.
> ----
> 
> I'd argue that as long as you think your app through then MySQL could
> be
> a great choice.
> 
> Guy
> 
> 
> 
>

Other related posts: