Q:
Performance of very large SQL Server table with millions of rows
SQL Server performance, SQL Server maintenance, SQL Server administration, Very Large Databases, SQL Server database design and modeling, Database design Performance of very large sql server table with millions of rows:
- I have a SQL server database
- I have more than 200 tables in the database
- I have one table that contains information on every row in all the tables. So this table will have millions of rows (Let us name it Bigtable)
- Any data modification (insert, update, delete) on any row in any table in the database will make the same operation on the relevant row in the Bigtable, so we have a lot of data modifications in this table,
- Any query on any table will join Bigtable to get relevant data from the Bigtable. (so there will be a lot of joins to Bigtable
MY QUESTION: is there a problem with such a design; What about performance, indexes ??
- I have a SQL server database
- I have more than 200 tables in the database
- I have one table that contains information on every row in all the tables. So this table will have millions of rows (Let us name it Bigtable)
- Any data modification (insert, update, delete) on any row in any table in the database will make the same operation on the relevant row in the Bigtable, so we have a lot of data modifications in this table,
- Any query on any table will join Bigtable to get relevant data from the Bigtable. (so there will be a lot of joins to Bigtable
MY QUESTION: is there a problem with such a design; What about performance, indexes ??
ASKED:
Feb 6 2009 0:57 AM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
A:
RATE THIS ANSWER
0
Click to Vote:
0
Click to Vote:
- 0
0
If the values in the columns on BigTable will all exist for all the rows then it is probably an OK design. If the rows which have parents in TableA have different columns filled out than the rows whos parent is in TableB then it isn't such a good design. In this case each parent table wshould have its own child table with only the needed columns included.
Have a table with millions of rows unto itself isn't a problem.
