List:General Discussion« Previous MessageNext Message »
From:Brent Baisley Date:May 22 2007 1:47pm
Subject:Re: design choice - quite many tables
View as plain text  
It seems to me that you are asking about Merge tables. A merge table allows you to
"combine" 1 or more tables to appear as a single 
"virtual" table. What tables make up the merge table can modified quickly and easily,
regardless of size. Then your code only needs 
to reference 1 table name.

There are limitations to merge tables (i.e. can't be InnoDB), so you need to read up on it
to see if it will work for you.

----- Original Message ----- 
From: "Przemysław Klein" <p.klein@stripped>
To: <mysql@stripped>
Sent: Tuesday, May 22, 2007 3:57 AM
Subject: design choice - quite many tables


> Hi All.
>
> I'm working on quite big database. It consists of about 200 tables. Additionaly about
> 50 tables are per year (because of annual 
> data). It means every year new 50 tables will have to appear in application. And now
> I have a question. Should I use separate 
> databases for "annual" data (i.e. db2006, db2007, etc...) (i don't need constraints
> on that (annual) tables) or put all the tables 
> in one database? Is there any way to 'catalogue'/organize tables within one database
> (namespace/schema)?
> Any thoughts?
> Thanks in advance...
>
> -- 
> _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
> Przemek Klein (p.klein@stripped)
>
>
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/mysql?unsub=1
> 

Thread
design choice - quite many tablesPrzemysław Klein22 May
  • Re: design choice - quite many tablesBrent Baisley22 May
  • Re: design choice - quite many tablesMartijn Tonies22 May
    • Re: design choice - quite many tablesPrzemysław Klein23 May
      • Re: design choice - quite many tablesWm Mussatto23 May
        • Re: design choice - quite many tablesPrzemys?aw Klein24 May
          • Re: design choice - quite many tablesWm Mussatto24 May