There's so much to learn in this industry, and not everybody has the necessary interest.
Originally posted by Ulf Dittmer:
What exactly do you mean by "report display in the front-end"?
Originally posted by Ulf Dittmer:
The app/web server wouldn't have to poll the DB every time one of the clients asked for updates - it could itself check in with the DB periodically, and prefetch the required data if there was a change. Thus the DB load wouldn't rise if there were more and more clients.
Originally posted by Ulf Dittmer:
Most Databases have a concept of triggers that can be fired automatically if certain events (like a table change) occurs, but I would shy away from using that to reach outside of the DB. That would be a twisted design.
There's so much to learn in this industry, and not everybody has the necessary interest.
What do you mean by the app/web server checking in with the DB periodically? Does this mean that I would have to create an object that continually queries the database for changes, say every minute? Wouldn't this affect performance, as a database query is done every minute?
Also, I am not sure how to go about the checking for updates in the database. Should I have a counter for the number of rows in the table and prefetch the data if the value of the counter changes? What if the user only updated a row? Does this mean that I would have to check every record against the old ones?
Yes I am considering the use of triggers. I am interested to know though why you think this would be a twisted design.
There's so much to learn in this industry, and not everybody has the necessary interest.