Rick Widmer wrote:
mlist wrote:
John Simpson wrote:
and since mysql has a limit of 64 bytes for a table name, you have
a... maybe not a bug, but a design flaw. the name "aaaaa(63
times).com" IS a valid domain name, but "aaaaa(63 times)_com" is NOT
a valid table name.
Definitely a design flaw, even before the domain name length increase.
I believe Ken once told me it was a mistake, but he never removed it
because people were using it. I think the name length issue is a good
reason to depreciate the feature. I'm looking to reduce the number of
options to ./configure, and this looks like a good candidate.
perhaps you shouldn't store each domain's data in a separate table?
i've never understood the reason for creating separate tables for
each domain anyway- but since i don't normally use a SQL back-end
for mailbox information, it's not something i really worry about.
Well then . . . that explains it. Thanks Rick, Joshua, and John.
I'm no full-time DBA wouldn't it take less time to query through a
specific table looking for data than it would to query one massive
table? Any one else have any thoughts? I'm curious to know which
would perform better.
If I remember right, speed was the reason for separate tables, but
testing showed it was not faster. I think the single table works
better because all your mail users are accessing the same table, and
its indexes so they stay loaded all the time. If you use separate
tables it is always thrashing the cache as different files need to be
accessed.
I was going to ask about why that option was still available (seeing as
how it's widely disliked) but I didn't want to seem ungrateful.
If in the future it is deprecated does anyone have an idea on how to
convert many tables to one? I'm sure I could piece together a shell
script but I know there are a lot better scripters out there than me.
Matt
