I'm a 

* start with postgres approx 1996
  - it was out there and simple... 

* migrated to mysql (for speed) approx 1998
  - was gazillions of times faster than postgres
    (postgres was slooow for the average transaction)

* migrated back to postgres approx 2000
  - postgres improved vastly in speed (still not as quick as mysql
    ... but that is not its mission)
  - supported constraints and most importantly triggers/foreign keys
    ... i can't live without foreign keys anymore... at all...
    have numerous tables like: 
        - users (has primary key id)
        - plugin developer develops "users_extended" (sets foreign key
          to id with auto-update/delete cascading)
        - plugin developer develops other table dependent on users (id)
        - etc etc etc
    If a user is deleted, all user data from all tables is deleted
    (taken care of by database).

    - This would just not be possible without foreign keys... the
      application would *need to know* about any additional tables being
      added and as such, the update/delete functions would need to be
      updated in the core, making plugin development very cumbersome. 

    - Another fantastic feature is 'transactions'... can't say enough 
      good things about them :-) 

If mysql is "better" because its smaller, why are they suddenly now
starting to support all these features, which no doubt will slow it down
(putting it on par with postgres)... 

Horses for courses i say, but i *currently* like postgres much better
due to its feature set... which enables clean separation and programming
:-) 



On Thu, 2004-08-12 at 15:14, Mathew Robertson wrote:
> > > you are kidding right?
> > 
> > Not at all.  That doesn't mean I expect to convince anyone though.
> > This is the kind of wisdom that usually only comes from experience!
> 
> I'll ignore that...
> 
> > > ACID capabilites and all that...
> > > proper locking semantics...
> > > long history with native support for transactions...
> > > proper SQL transaction semantics...
> > 
> > Over-rated.  Sure, if I was building banking software I might have a
> > different opinion, but I'm not.  A simple database with few critical
> > bugs protects my data better than your fancy ACID transactions!
> 
> :-)
> 
> > How can I be so sure?  I've worked with big complex systems running on
> > both databases.  I've watched Bricolage completely destroy user data
> > despite using PostgreSQL's transaction support.  In contrast, Krang
> > hasn't lost data yet, as far as I know.  A few careful locks in the
> > right places seem to be just what the doctor ordered for a moderatly
> > complex content management system.  And if the catastrophic happens,
> > like a system crash, that's what nightly backups are for.  Nightly
> > backups might not be good enough for all applications, but they're
> > good enough for a content-management system.
> > 
> > > As you said, people can make spaghetti out of anything - how this
> > > makes MySQL 'better', I dont understand.
> > 
> > Experience.  Wrestle with a database strewn with triggers,
> > constraints, abstract types and functions sometime.
> 
> umm - yes, I do this already... the cluster I am currently involved in building is 
> meant to store 100+ billion records... see below...
> 
> >  You'll be begging
> > to be back in the moderate mess of a badly designed MySQL DB.  There's
> > less there so there's just less to do badly.  It may not be an
> > emperical fact, but I didn't presented it as such!
> 
> My team is currently building a "Parallel query cluster" (eg "PARALLEL hash(id) 
> SELECT id,value FROM row_data WHERE some_clause"), such that we are building the 
> 'PARALLEL hash(...)' bit.
> 
> The idea is that you have a cluster of say 100 nodes, with various schema such a 
> foreign keys, etc.  Then you query it from you data processing engine...
> 
> ... given that I have been using databases since I left uni at 24 (I am 31 now), I'd 
> say that I have enough experience...
> 
> We prefer Open Source tools (which is why we use H::T), high reliability and high 
> performance -> we chose PostgreSQL over Oracle; MySQL wasn't even a consideration...
> 
> 
> In any case, I personally think that MySQL is good enough for most tasks; and since 
> this is a little off-thread for H::T, I'll now shut my big fat trap...
> 
> Mathew
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Html-template-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/html-template-users



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users

Reply via email to