On Mon, 2010-05-17 at 09:28 -0400, Phil Howard wrote:
On Fri, May 14, 2010 at 17:48, Noel Butler noel.butler@ausics.net wrote:
MySQL makes it such a dream, even with customers adding aliases and so on, its a simple instruction to mysql via the web portal from them, and using replication means every front end has its own local copy, and able to fallback to the master if for some reason it becomes unavailable (never seen that in all the years been using it tho, but its nice insurance)MySQL (or PostgreSQL, etc) has its place. And for things like CRM with a lot of different aspects, that is the way to go. But even then, I would (and have for other purposes) just export the data out of the SQL database and build a fast index like CDB. However long it takes to build CDB is NOT downtime; it's just lag from data entry to activation. And there are ways to work around that if the lag is an issue, such as having
I guess you've never used it with tens and tens of thousands of users, let alone user numbers well into 6 figures and why on gods (or any) earth would I use that load of crap being backed up by another form? that clearly makes no sense, we have backup provisions being mysql replications sure but thats nothing like what you do. your method is pure insanity in this day and age.
a CDB first, followed by another lookup that may have the most recent data. For example, when the list of new users arrives, add them to a Berkeley DB that is queried next when the CDB has no match. Thus they work even while the CDB (think of it has a static cache) is being rebuilt. One thing I would NOT do is have mail servers hitting the CRM database (or its replicas) directly. It's not a performance issue; it's a security issue. The larger the operation, the more important this is.
I guess you've been bitten by a proper database solution given your apprehension for using one.
its your network (I hope for your sake).. its up to you how efficient it is.CDB is very fast.
yes it is, if you only have a small number of users.
(please use reply to list, not reply to all)