It's not that odd an environment, but I've found that with all the various apps we're running on DBs, updates are usually the least common transaction, inserts the next, and reads the most common by a margin -- and this is where caching shines. Updates also aren't that costly, since IB/FB, as most DB engines, supports a write-through cache and commits changes to disk when idle. I've seen small tables with a high ratio of updates vs. reads (1:3, 1:4) occasionally, but this was a result of the programmers choice to put temporary operating data into the database, rather than into memory.
> -----Original Message----- > From: Steven Critchfield [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 10, 2005 10:45 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: RE: [Asterisk-Users] OT: Best DB > > > On Thu, 2005-03-10 at 08:57 -0600, Jay Milk wrote: > > IB/FB stores the DB in one file, but the file can span > multiple drives > > if needed. However, you can't select which table goes into which > > file. Personally, I don't think that's very feasible, nor is it > > required -- if a table is accessed often enough to be mission > > critical, large parts of it will reside in memory due to caching > > anyway. > > Maybe I work in an odd environment where writes(updates and > inserts) are probably equal to or more than the reads. > Caching isn't real helpful at making the data get to disk > faster. Caching helps for reads only. _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
