Question

i have a database with client data, all client data is stored into a single table and are uniquely identified by a client code normalised into another table, eventually we will have 100+ clients all in the same table, each year the client data for every client will double, 1000+ rows of data a year per client.

what are the pros and cons of dividing each client into there own table and querying them by tablename instead of by client code, and will 100+ tables be unmanageable, and considering how much data we will eventually have is it even necessary to change anything ?

Answer 1

This is an odd question, but really I don’t think you have anything to worry about, keep your database normalized (which you said you already do).

Leave it all in one table, it is a database, let it grow, don’t worry that it will be 10k rows after 2-3 years.

I have dealt with large mysql/mssql installs and they work just fine on single servers with millions of records.

So no, don’t break customers up into tables, it creates a management nightmare, stick to one, make it normalized and leave it be unless you run into problems.

EDIT

As you are still concerned, here is a direct copy from MYSQL:

Scalability and Limits:

Support for large databases. We use
MySQL Server with databases that
contain 50 million records. We also
know of users who use MySQL Server
with 200,000 tables and about
5,000,000,000 rows.

Support for up to 64 indexes per table
(32 before MySQL 4.1.2). Each index
may consist of 1 to 16 columns or
parts of columns. The maximum index
width is 1000 bytes (767 for InnoDB);
before MySQL 4.1.2, the limit is 500
bytes. An index may use a prefix of a
column for CHAR, VARCHAR, BLOB, or
TEXT column types.

http://dev.mysql.com/doc/refman/5.5/en/features.html