Re: webmail user mailbox schema design?

From: <johnbhurley_at_sbcglobal.net>
Date: Fri, 1 May 2009 11:11:08 -0700 (PDT)
Message-ID: <938acc33-25f0-4d53-83d5-e70f4a73d47c_at_g19g2000yql.googlegroups.com>



On May 1, 1:51 pm, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:

snip

> > Partitioning the MESSAGES table on user_id could provide speed and
> > manageability by segregating each users messages to a single
> > partition; partition pruning would eliminate visits to unrelated
> > partitions effectively reducing the data set to a fraction of the
> > total number of messages stored.
>
> I struggle to understand a single advantage of partitioning. Well, you
> listed one advantage -- easy deletion. However, since when deletion
> became a determining factor in database design?

Well it was just a shot in the dark by ddf with a little bit of thought but no clear specifications at all from the OP.

I don't really think that being able to delete email messages may be a viable proposition for most mail providers beyond a very small mom and pop type of thing that is somehow not getting regulated but could be wrong here.

>
> Let me list disadvantages.
>
> - It is just yet another complication on top of already messy vendor
> implementation. A partitioned table is fundamentally a union view;
> some database vendors (oracle), however, have decided that it is
> something completely different.
>
> - I refuse to understand why a single solution - table - doesn't
> scale, and where the demarcation line between "small" and "large"
> lies.

Well you would need a clear design and some specific testing methodology.

Partitioning does seem to get heavily overused and in many cases thrown in without justification.

> The idea that DBA have to revisit that table definition every quarter
> is just beyond me. Apparently oracle DBA has too little to do than to
> tell computer in details how to organize its storage in each and every
> minute detail. I propose browser vendors roll out a special DBA
> edition where a user has to explicitly allocate heap memory for each
> web page.

There's a lot of improvements recently in how much time and effort is spent managing this area.

> And I'm not even going into kitchen sink of subpartitions...

Seems like you are going a little off course here from the idea in the beginning of this thread. Received on Fri May 01 2009 - 13:11:08 CDT

Original text of this message