if this is new, (since you said the users will enter) a better solution would be to design and use a proper database (normalized and indexed)

We don’t even know what the application is going to do with those records.

If you really want to get answers you will have to provide more details.

P.s. But as BigKat suggested, the first step would be to re-design the database.

it is a salary system
contain salares of up to 27000 employ
salary table have 37 column
every month i must Generate new 27000 rows with same data of Previous months rows in the salary table (i make function with vb.net to do this) normalization will make the generation of next month row so Difficult

what I’m concerned about is the possibility that the program Will have a bad performance or give (out of memory massge) when the rows numbers will increased by time in the future
AND does paging solve this problem and prevent it from appearing?

best regards

Unless you have a really small database server, performance shouldn’t really be a problem. 27000 rows per month is nothing - 300,000 rows/year or 3 million rows over 10 years.

A payroll type of application really should be normalized. As others have said, there are probably a lot of the 37 columns that are repetitive from month to month (i.e., all the information about the “person” [name, address, phone, title, employer, employment status, etc.]) while the “dynamic” information (hours worked, pay amount, deductions, etc.) could definitely vary from month to month.

However, normalizing the data in such a small database isn’t going to affect performance that much, as long as you have some “key” information on those rows. You need at least a transaction date/time field, a payroll period identifier field (or at least a period start date/time and period end date/time field), and a person identifier field. With those, you can probably query the information fairly effectively.

When designing a database, the proper first step is really to try determine what information is going to be required FROM the database and with what frequency. Then design your database to optimize for the most frequent (and most important) uses.

thanx kccrosser

but !.
in my case i have all the 37 column are Repeated monthly ( Except name column )

Because of that in normalization i must repeat rows with more that one table
so i dont want to have normalization
is there any proplem if i have table with 37 column

There is no problem with tables of 37 columns or more. Most database systems will allow up to 255 columns (although that would likely be a very poor database architecture). I am working with production databases with millions of rows, and there are 39 normalized tables (of 1423 tables) in that database with over 50 columns each.

There are many good books (and online articles) on database normalization and the reasons to normalize a database. However, normalization isn’t necessarily going to improve performance, and can often slightly degrade performance. Normalization is primarily intended to avoid data redundancy and generally make database maintenance and navigation easier.

thanx kccrosser

Pay Stub, 37 columns makes total sense to me.
- there are all those things on your pay stub that are unique to the SSN-Year-Month even when they typically have the same values (like number of dependents).

And this stuff needs to be retained forever (until years after the person dies) but not necessarily in a single table. Perhaps a different tables for each year???
With a view to pull them together for reporting..

So your question is how to generate 27000 rows for 20111101 similar to 27000 rows for 20101001 and you’re worried about the client/server transfers and client memory of 27000 rows.
- this doesn’t need to be a client process
- the client can kick off a stored procedure in SQL Server.to generate all 27000 rows.
Phil

So your question is how to generate 27000 rows for 20111101 similar to 27000 rows for 20101001 <<– this should have been 20111001 –> and you’re worried about the client/server transfers and client memory of 27000 rows.
- this doesn’t need to be a client process
- the client can kick off a stored procedure in SQL Server.to generate all 27000 rows.