I have a poorly designed database. One of the most important tables has 11,000+ entries. We would like to expand our system, and I am wondering if this table grew to 5x its size, would this be a problem? It's 15360 kB in size... if that matters.
I'm using phpMyAdmin, the server is a Fedora Linux box (nothing fancy), The load is light. It stores just about everything our system uses.
What DBMS? What server? What load? What application?
Besides: 11.000 records are nothing, really. Even in MS Access. :-)
EDIT: So I assume you use a fairly recent MySQL with MyISAM tables. In theory, you can go ahead and fill the table into the millions of records. Depending on how you work with them (lots of joins / or not, lots of queries/updates/deletes / or not), you don't need to do anything special. Put a proper index on the table and you should be fine.
What do you mean by a "poorly designed database"?
If it's badly designed, redesign it, drag the information out fo the current tables, and populate the new one.
If you're concerned about performance, 11000 entries is not big. A 15 megabyte database is extremely small, by db standards.
I don't think you're providing enough information for someone to give an answer. Why is it poorly designed? Is it not normalized? Do you not have any indexes? What DB is it? What OS is it running on? How long does it take now to query a record from the table in question?
A bad foundation will be your most costly mistake. If the table is important, then you need to decide how important it is to fix it. The amount of rows in a table only affects the speed at which you can pull stuff out of it. But, if you've got a bad database design to start with, your hands will be tied at certain places down the road.
11k entries is not that many. 50K is not large either.
Putting indexes on the table (optimized for the queries you will run on it) will allow good performance for much larger amounts than what you are envisioning.
If the design is poor enough though, you might look into the cost of redesigning.
The size of a table isn't very important. The design of the key, indexes, and relationships have much much more to do with the quality of the design than does the size of the data contained in it. There are obviously caveats to this; but optimizing the size of a table is near the last thing I do when working on a performance or design problem.
You may want to explain more about why you think this is a poorly designed database and what things you can (easily) do to correct the issues. Along with that you should detail the type of DBMS and what the usage is (web app, custom app, reporting, etc).
15MB is nothing. 11k rows as well. I have databases with 2+ GB of data, with some tables containing over 1 million rows and I consider that being somewhere between small and medium size.
You really didn't give any evidence to support your claim that this is a poorly designed database. What makes it poorly designed? does the table have 876 columns? Are the columns named Col1, Col2, Col3...? Does it use a float and a datetime as a composite primary key? It is poorly normalized? The only thing we know about is it's record count.
If you are talking about SQL Server 2005, look into SQL Server profiler and use Index Tuning wizard.
There is also support in some databases for table pinning to memory if you want additional performance.
What a record is comprised of can matter more than how many records are in a table.
Where I work we have databases with numerous tables having record counts in the tens of thousands or hundreds of thousands. Our databases are considered small, for the most part.
11K records is usually nothing in database terms.
What else makes you think the database is poorly designed apart from the number of records in the one table?
You need to give a lot more information about the table structure.
In general, 15,000 rows in a table would be considered small, in fact so small, that some designers might not even bother with indexing it.
I understand that you are worried if increasing the number of records to around 55.000 in"your poorly designed database" will affect performance.
If you system works as expected now I think you should be fine with 50.000 records as well unless you have some slight performance issues already.
As most people mentioned 50k records is a very small number in relation to database table size and even with not normalized database there should be no performance issues.
If you are planning to expand the functionality of you system then perhaps it would be a good time to look at the database design as well, otherwise it should be reasonably safe to leave it as it is.
If you are going to expand your system, now is the time to redesign if need be. It is much less painful to redesign when you have 11,000 records than when you have 10 million. However, nothing you have said indicates to me that you need to redesign. There is nothing inherently wrong with having joins (in fact a well designed database should have them). Post some details about the struture and we can help you decide if redesign is needed.
It is possible that the problem is that you and your colleagues are simply not experienced at database access and do not know how to effectively and easily query them. Or the problem could be that the design is bad, without details of the structure, it is hard to say.