I suggest you reply to the mailinglist :-) ...
> The developer insists that for scalability issues, this was the
> answer. It is likely, for example in my deployment, that these tables
> would see upwards of 10 million records or more.
Well, if there are problems with scalability, I guess you could
split it up in a few (not 1600) tables and have them avaialble
on different physical hard drives...
But -> why try to fix something that ain't broken (yet)?
Were you experiencing problems already? If the application
is fast WITHOUT merge tables, why bother?
Database Workbench - development tool for MySQL, and more!
Database development questions? Check the forum!
> > > One of the databases I use just switched to using merge tables and now
> > > my queries are painfully slow. One table, initially had about 2.5
> > > million records and now with the change this information is spread
> > > across about 1600 tables. A simple query, say select count(*) has gone
> > > from .04 to about 30 seconds, sometimes even longer.
> > Why on earth would you spread this information across 1600 (!!!)
> > tables? That's 1600 files to maintain instead of 1.