Our application has a table which stores all transactions records of clients in one single database table which has a auto-generated key as primary key. We have started to receive around 25K records each day now and am started to wonder if this at some point of time will cause a performance issue.
Background:
Transactions table contain all the details of each transaction our client (in real world, they are food vendors{say Kellogs cereals} and distributors{say Walmart}) perform every day. Initially, the design did not specify any logical/functional field that could serve as a primary key for a transaction and hence the DB developer went ahead and added a auto-generated key to “fill-in” the primary key. Since the client need to have all information on the front-end, the query is always SELECT * FROM TRANSACTIONS. The table has close to 80 columns and now has grown to 100K records.
Database: Oracle 11g
Core business logic implemented in: Java 1.5 (JDBC driver for querying)
Front-end : SmartGWT
Query:
Assuming fetching all the records all the time will start hammering the performance at some point, I wanted to seek any database design / query tweaks / general suggestions that I should consider to avoid performance issue or improve performance of the module.
Oracle 11 lets you create interval partitions. I think transaction date is a good candidate for partition key. I don’t see any reason to show all the transactions to end users ( at least every time). Usually it’s enough to display just last week/month data… Retrieving complete list of transactions can be handled differently (storing consolidate balance, using readonly tables that keep historical data, etc).
Also, having 80 columns in a single table looks quite suspicious to me.