By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,379 Members | 1,435 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,379 IT Pros & Developers. It's quick & easy.

SQL Table

OuTCasT
100+
P: 374
Can anyone tell me how many columns/rows a table can handle before becoming slow and unusable ?
Apr 3 '08 #1
Share this Question
Share on Google+
5 Replies


ck9663
Expert 2.5K+
P: 2,878
I have processed, 15 million rows - by - 100 columns. I just process 380 columns by 60 rows...Everything is working, at least according to the execution time I am required to produce.

-- CK
Apr 3 '08 #2

OuTCasT
100+
P: 374
I have processed, 15 million rows - by - 100 columns. I just process 380 columns by 60 rows...Everything is working, at least according to the execution time I am required to produce.

-- CK
The reason why I ask is because im busy writing a payroll solution, with several tables, employee, deductions, companyContributions etc and i dont want to make it complicated by joining the tables together and saving the information back....would it be a prblem if i used the one table with all that information in it, obviously there wont be so many rows since i dont think many companies have more than 50 employees. just the columns will be extensive and at a later stage be more than 100 columns.
Is it better to use multiple tables instead of 1 table.
Apr 4 '08 #3

ck9663
Expert 2.5K+
P: 2,878
Since it's a payroll system, I'd go for the multiple tables. It will also follows the discipline of a Relational Database. Since SQL-Serve can be considered as Relational Database, you can save a lot of time enforcing data integrity and consistency on the database level and not on the apps side.

You also have to remember that you will have monthly or semi-monthly transaction (depending on how payroll is processed), including handling of deductions.

-- CK
Apr 4 '08 #4

OuTCasT
100+
P: 374
Since it's a payroll system, I'd go for the multiple tables. It will also follows the discipline of a Relational Database. Since SQL-Serve can be considered as Relational Database, you can save a lot of time enforcing data integrity and consistency on the database level and not on the apps side.

You also have to remember that you will have monthly or semi-monthly transaction (depending on how payroll is processed), including handling of deductions.

-- CK
Well its only monthly transactions. there will be a table for earnings and deductions, most of the screens will use information from these 2 tables.

this is fairly easy. What i would like to knw is the month end procedure that will update all the tables with the recent data AND insert the Month data into a MonthEnd table for record purposes.
Is it possible to create a .dll to handle these procedures ??
Apr 4 '08 #5

ck9663
Expert 2.5K+
P: 2,878
If all data are in sql-server, I'd recommend stored proc.

-- CK
Apr 4 '08 #6

Post your reply

Sign in to post your reply or Sign up for a free account.