November 4, 2005 at 2:49 pm
I have a small DB that is 1.6 GB's and is growing. This DB has grown 3x's it's size in the last year and although we are still small we won't be forever. I have a table in paticular that is a directory table that has 24 columns in it and 17,000 records. I have considered creating a new table (approx. 6 more columns but could be more in time) to house additional info specfic to the entries in this table. At what point should a new table be considered. Is it creating more overhead (performance,space and administration) to create a new table (unique ID,active bit,entered date,updated date plus new information) or just add these 6 columns to the main table? When does a table become too full? If anyone has any good links or comments I'd appreciate them. TIA!!
November 4, 2005 at 3:17 pm
A table is too full when the indexes and load do not allow for optimal performance. 17,000 rows is a tiny table. If you are having performance issues, look at the table structure design, index strategy, query execution plans, etc. I have tables in one of our databases with 200 million rows that perform fine.
A.J.
DBA with an attitude
November 4, 2005 at 5:56 pm
Size isn't the determiner of where data should go. If the data you want to add relates to the primary key of the base table, the whole primary key, and nothing but the primary key, it belongs in the base table. Otherwise, put it somewhere where the above statement can be true.
I'd agree with awilbur77 that a 17,000 row table is trivial and would not, in itself, cause a problem. It's possible, though, as he said, to have a badly designed query or an inadequate index scheme that forces multiple table scans, degrading performance.
IF you post the query, the ddl for the tables involved, an example of the desired output and a statement of what the slow-running query is expected to do, the folks on this forum can probably give you some good advice on making things both faster and more efficient.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply