I need feedback on a database implementation I plan on using.
I need feedback on a database implementation I plan on using.
Because a lot of what my application does is "What-if" stuff, I plan to store the customers information in a set of base tables. I'll copy the selected master-detail items into a set of work tables. Let the customer play around with the data in these work tables as much as they want. When they are done I'll update the base tables from the work tables.
I plan on hooking up data-aware controls to these work tables. I plan on using the Data-Aware-Control.OnExit method to post changes back to the work tables.
Has anyone implemented this in your applications?
What are the positives and negatives to this approach?
TIA
Because a lot of what my application does is "What-if" stuff, I plan to store the customers information in a set of base tables. I'll copy the selected master-detail items into a set of work tables. Let the customer play around with the data in these work tables as much as they want. When they are done I'll update the base tables from the work tables.
I plan on hooking up data-aware controls to these work tables. I plan on using the Data-Aware-Control.OnExit method to post changes back to the work tables.
Has anyone implemented this in your applications?
What are the positives and negatives to this approach?
TIA
If you update the base tables, the users of your app are bound to one set of "what-if" scenario per session. Would this work in your case? From what you write, I feel that it would be more useful if you introduced different configurations (or "what-is" cases) but there is not enough info to figure out what fits in your requirements
ReplyDeleteAnd you case save the different scenarios in XML format and when the user finalises the decisions then you store everything in the base tables---Just throwing ideas
ReplyDeleteBased on your descriptions, I would probably look into using some memtables like (FDMemTables or ClientDatasets) where I easy could clone the base tables, and store the various deltas from the what-if scenarios - and store them as json data - to apply or discard later. I use this approach for sand-boxing and simulation where the user wants to experience the consequences of their data changes prior to applying the to a "live" environment.
ReplyDeletemost "what if's" scenarios can be solved with database transactions
ReplyDeleteDorin Duminica agreed, it the user only has one short "what-if". But if they do what to keep it for later - and they do what to compare with other of their "what-if's" - for that in-memory tables are fast and easy created, saved or discarded - even without hitting the DB all the time.
ReplyDeleteSounds like the briefcase model with cached updates. In the past you could do this from BDE or ClientDataSet. Nowadays there are many more possibilities but they all come down to those old techniques with respect to "what to watch for" (primary keys, order of updates, etc).
ReplyDeleteThank you all for your responses. I apologize for not giving enough details. The database I'm talking about is a single user ElevateDB database.
ReplyDeleteI've never used data-aware controls before. Most of the data-aware examples I have seen show a dbGrid, dbNavigator and several data-aware controls all wired together. If you modify the data in one of the data-aware controls, that modification is updated as soon as you navigate to a new record in the dbGrid.
Since I won't have the dbNavigator or dbGrid I was planning on using the OnExit method of the data-aware controls to post updates to the work tables.
I was looking for validation that the OnExit method is an acceptable way to do database updates.
I would try to refrain from Cached Updates. But mainly because i love the centralized transaction and error handling on ACID RDBMSes. That comes from what clients i have and their needs (so may be very different for you). Error resolution can become a b#tch if you really want to use your DBs strengths.
ReplyDeleteI have also decided to skip a beat and not touch FDMemTable since 1) it's very costly 2) detailed support and fast fixing of bug is not Embas strong side and 3) my trials did not make me very happy.
If you plan on using a TDataset on both server and client, then maybe check out TeeBI here in the group. It's still very raw but essentially it's about analysis and "light weight". All-in-all do you need all the stuff in TDataset / FDMemTable on the client? Maybe something more light-weight would fit. Depending on your data-editing needs at the end (end-user) if they are "small" you could write some specialized function. Then the complexity of most of your datastores will lower considerably.