As I said on my earlier message...
Table structure would be some thing like
- message_folders
-- id PK
-- user_id (FK) - Indexed
-- name varchar2
-- created_at timestap
- Conversation
-- id PK
-- folder_id (FK) Indexed
- messages
-- id PK
-- author_id (FK)
-- Recipant (FK)
-- Subject varchar2
-- Body varchar2
-- attchment_name
-- author_deleted boolean
- Recipant_deleted boolean
-- date_sent timestamp
- Conversation_messages
-- conversation_id Indexed
-- message_id - unique
Sudhir NimavatSenior software engineer.
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India
Personally I'm always ready to learn, although I do not always like being taught
________________________________
From: Raj Shekhar <rajlist@stripped>
To: mysql@stripped
Sent: Thu, 5 November, 2009 10:58:34 PM
Subject: Re: Fw: 50M records each year.. how to handle
<sudhir543-nimavat <at> yahoo.com> writes:
> But app will need to create a new table every year and alter merge
> table definition..
Right. ALTER table on a merge table is a fast operation. A MERGE
table need not maintain an index of its own because it uses the
indexes of the individual tables. As a result, MERGE table collections
are very fast to create or remap.
> However I doubt that merge table would give a decent performance for
> Select operaton..
I cannot comment on the above statement without seeing your table
indexes and your select queries. If you use optimal indexes, you will
have fast selects.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=1
Now, send attachments up to 25MB with Yahoo! India Mail. Learn how.
http://in.overview.mail.yahoo.com/photos
