No offense but I've seen people on the list throwing replication around like
MySQL has replication end of story. There's alot more to replication than just
a master and a slave. What MySQL has is simple unidirectional replication. If 
you want advanced or bidirectional replication you'll have to be able to 
handle issues such as conflict resolution , queuing, etc.

I think a mixed bag approach of Oracle and Mysql would probably be a good
solution, but better yet, get the manager to really define what he wants to
do. You may find the unidirectional replication is sufficient. 

Dave
> No surprise that these folks haven't been following MySQL development 
> for quite a while, and probably don't know about its replication 
> features. I haven't used 'em myself, though, so I can't vouch for 
> their robustness.
> 
> As far as the feature set & manageability, it's true - there's a 
> lotta things MySQL made a conscious decision to leave out (unions, 
> views, triggers, stored procedures, subselects [i know, coming soon], 
> foreign key support, etc.) in favor of speed/small memory footprint. 
> And you have to go to third-parties for 
> reverse-engineering/diagramming tools.
> 
> If your application requires such, then maybe MySQL _isn't_ the right 
> solution; however - depending on your app - Oracle/DB2/whatever might 
> be sheer overkill. Administrative overhead for systems like those 
> might far outweigh any advantages they have for you.
> 
> 
> >There are question marks around the scalability of the product, I'm not
> >sure of the locking algorithms used (whether row level or record level) -
> >the
> 
> 
> It depends on table type; AFAIK, it can be table (ISAM/MyISAM), 
> page-level (BDB), or row-level (InnoDB). See:
> 
>       http://www.mysql.com/doc/L/o/Locking_methods.html
> 
>       http://www.mysql.com/doc/T/a/Table_locking.html
> 
>       http://www.mysql.com/doc/I/n/InnoDB_Next-key_locking.html
> 
> You've got a choice! This used to be considered a good thing...
> 
> 
> >fact that it is not generally used in multi-user solutions is a good enough
> >indication that this is not accepted database technology for
> >industrial-strength
> >multi-user systems.
> >The fact that it is unsupported freeware would mean that an end user would
> >potentially be "held to ransom" by a DBA with specific knowledge.
> 
> 
> This kinda of statement is beginning to REALLY rile me when I hear 
> it. Even if you discount the fact that this mailing list provides 
> better support than the majority of PAID support programs, if you 
> want to, the MySQL folks would be more than happy to take a large 
> amount of your $$$ to provide excellent support:
> 
>       http://www.mysql.com/support/arrangements/types.html
> 
> - this can include customizing MySQL for you! There are also 
> individual consultants & firms that will support you as well. How 
> anyone could actually back up a claim of MySQL being 'unsupported' is 
> beyond me.
> 
> 
> >The mySQL
> >security model is also not sufficiently developed for any system that
> >involves
> >money.
> 
> 
> I dunno, with some combination of encrypted fields, database server 
> behind a firewall, SSH-tunnelled communication and good DB/system 
> administration, you'd have a plenty secure system. After all, I don't 
> think any of the recent and not-so-recent credit-card number thefts 
> have been on MySQL systems.
> 
> OK, back to work for me. But first, some Mountain Dew...
> 
>       -steve
> 
> 
> -- 
> +------------------------ Open source questions? ------------------------+
> | Steve Edberg                           University of California, Davis |
> | [EMAIL PROTECTED]                               Computer Consultant |
> | http://aesric.ucdavis.edu/                  http://pgfsun.ucdavis.edu/ |
> +----------- http://pgfsun.ucdavis.edu/open-source-tools.html -----------+
> 
> ---------------------------------------------------------------------
> Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)
> 
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to