Re: dynamic tablenames

njmacinnes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Tue, 23 Jan 2007 16:21:55 -0000

Why not just have a table with >200m rows? As far as I''m aware,
there are no
real performance advantages with splitting it up. The point of a database is
that it can just eat up data without without causing any performance issues.

Although I can''t imagine what on earth you''d want to 200m rows
for! Modeling
the cells of a small rodent, maybe?

-Nathan

On 23/01/07, Piet Hadermann
<piet.hadermann-/1BeJOKqmzrQT0dZR+AlfA@public.gmane.org>
wrote:
>
>  Hi List!
>
> May I tap into your combined common sense ?
> I have a legacy logging app that needs to be modernized. At the moment,
> Data is going to be stored in 5 tables, one table is going to contain more
> than 200 million and 2 others about 60 million rows. Mysql will be used,
> unless someone sees a major advantage in using something else (at the
moment
> data is stored in a raw positioned file format, which I''m not
keeping).
>
> For performance reasons I''m thinking about storing the data for
each
> entity in separate tables. So instead of a ''logdata''
table with >200 million
> rows, I''d create ''logdata_001'',
''logdata_002'',... tables where the rowcount
> of even the biggest entity logdata stays below 3 million.
>
> Rails seems to have no problem with me setting the tablename
> (set_table_name) on each incoming request before accessing the database.
> I have this gut feeling though I''m overlooking something nasty.
> Anyone have any comments/suggestions ? Am I about to create my own
> personal maintenance nightmare ?
>
> Thanks in advance for your insights!
>
> Piet.