Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

What is the best method to store frequenly accessed data?

Status
Not open for further replies.

Nimmika

Programmer
Sep 15, 2010
6
LK
When developing retail POS system we want to access product master file frequently.Product master file is stored in a central database and a copy of the file is stored in a database in every outlet.There can be more than 15000 records in the product master.

Instead of accessing outlet database everytime(invoicing/product punching) can I use a dataset to store product data when loading the application.
 
I’ll give this a shot. I think I know what you’re asking?

Generally a retail system runs on a relational database that is always active and updating. Whether you use SQL or Sybase or Oracle, how the major pos developers work is that the database is running on the server and a smaller footprint of the same database on the work stations. The workstations point to the store’s server and continuously synchronize with it at a specified time interval. The reasons for the independent databases on every terminal is speed of accessing the data and redundancy. Redundancy is for when the server fails; the counter terminals can continue to ring sales with the last known good configuration of the database.
You write this so that when you synchronize, price changes, inventory, etc. go from the server to the work stations, and sales data and inventory negatives go from the work stations to the server. There is a lot more to it than that, but you get the idea.
If everyone is accessing the same database, you will have performance issues and most importantly, a central point of failure.

Does that help with the data set question?


Bo

Remember,
If the women don't find you handsome,
they should at least find you handy.
(Red Green)
 
Also 15,000 records isn't a lot. I just looked at one of my databases with one table with almost a million, and it can handle a lot more. I can grab what I want from this table in no time at all. When dealing with speed issues, be sure your sql statements are writen efficiently. With the table that has 15,000 records you do need to grab all of them at once? Also be sure to index key fields, this is huge for fast data access from large tables. As to using the dataset I'm not sure. At what specific point does this become an issue? / What are you doing with the 15,000 records at this time? A lot of this all depends on what database, programming language and how you are accessing the data. You're probably better off asking in one of those forums.


Tom
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top