Data Consistency
-
Imagine the following interactive mathematical application: - the data loaded in the application is split in two different 'types' - the first type, let's call it the 'interactive' side of the application, contains data that is manipulated (added, deleted, changed, ...) by the user. It's effect on other data can be immediately calculated and we can quite easily determine which parts of the screen needs to be redrawn to make the screen back consistent - the second type, let's call it the 'constraint' side of the application, contains data that is less frequently manipulated by the user. But if it is manipulated, it could have an impact on any element of the 'interactive' side. The problem is that there is no one-to-one relation between elements in the 'constraints' side and elements in the 'interactive' side. If we want to show the user an always-up-to-date 'interactive' view, certain complex calculations are needed which can easily take up several minutes. My current approach is to disable the 'interactive' side from the moment anything is changed on the 'constraint' side. The user can then continue to work on the 'constraint' side, but if he wants to go back to the 'interactive' side of the application, he will have to perform a full recalculation. Result: a slow, but always consistent application (regarding the 'interactive' side). The alternative could be to keep the 'interactive' side enabled while the user is changing elements in the 'constraint' side. Often the user can know what the impact is of his changes on the 'interactive' side and simply pressing F5 on the correct cell in the interactive grid can then calculate the effects from the 'constraint' side to that specific cell of the 'interactive' side. Result: a faster, but not always consistent application, meaning the user could draw conclusions from incorrect values. Does anyone of you have an application with a similar problem (choosing between slow and consistent or fast and inconsistent)? Any tips on how to have a fast(er) application with still having a quite good data consistency in the 'interactive' side? Thanks in advance for your tips.
Enjoy life, this is not a rehearsal !!!
-
Imagine the following interactive mathematical application: - the data loaded in the application is split in two different 'types' - the first type, let's call it the 'interactive' side of the application, contains data that is manipulated (added, deleted, changed, ...) by the user. It's effect on other data can be immediately calculated and we can quite easily determine which parts of the screen needs to be redrawn to make the screen back consistent - the second type, let's call it the 'constraint' side of the application, contains data that is less frequently manipulated by the user. But if it is manipulated, it could have an impact on any element of the 'interactive' side. The problem is that there is no one-to-one relation between elements in the 'constraints' side and elements in the 'interactive' side. If we want to show the user an always-up-to-date 'interactive' view, certain complex calculations are needed which can easily take up several minutes. My current approach is to disable the 'interactive' side from the moment anything is changed on the 'constraint' side. The user can then continue to work on the 'constraint' side, but if he wants to go back to the 'interactive' side of the application, he will have to perform a full recalculation. Result: a slow, but always consistent application (regarding the 'interactive' side). The alternative could be to keep the 'interactive' side enabled while the user is changing elements in the 'constraint' side. Often the user can know what the impact is of his changes on the 'interactive' side and simply pressing F5 on the correct cell in the interactive grid can then calculate the effects from the 'constraint' side to that specific cell of the 'interactive' side. Result: a faster, but not always consistent application, meaning the user could draw conclusions from incorrect values. Does anyone of you have an application with a similar problem (choosing between slow and consistent or fast and inconsistent)? Any tips on how to have a fast(er) application with still having a quite good data consistency in the 'interactive' side? Thanks in advance for your tips.
Enjoy life, this is not a rehearsal !!!
Hi, First of all I would not mind if you were to give a more concrete description of your app... Second, IMO if the app, due to changes in the constraints, is going to modify the interactive fields, then those fields must be disabled (or even hidden) for as long as they are unstable. It is completely unacceptable to have the user enter data and later find out it gets modified or even deleted automatically after a while. Finally if a calculation takes minutes, it is a candidate for optimization. No one wants to wait any longer than necessary in front of a screen. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Fixturized forever. :confused:
-
Hi, First of all I would not mind if you were to give a more concrete description of your app... Second, IMO if the app, due to changes in the constraints, is going to modify the interactive fields, then those fields must be disabled (or even hidden) for as long as they are unstable. It is completely unacceptable to have the user enter data and later find out it gets modified or even deleted automatically after a while. Finally if a calculation takes minutes, it is a candidate for optimization. No one wants to wait any longer than necessary in front of a screen. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Fixturized forever. :confused:
I'm afraid that's almost all the information I can give without going into the gory details. The problem is that in many cases, if the user changes constraint X it only has an impact on interactive field Y, and in 90% of the cases, the user knows this, but the application doesn't. The application can only know this after performing a global consistency check, which can take several minutes, due to the use of complex mathematical formulas. Compare this with pivot tables in Excel. Changing the slightest value in a sheet may invalidate a cell in the pivot table. Excel doesn't automatically recalculate the whole pivot table because it probably takes too much time, but in practice and in most cases the user could know what the exact effect is, and live without a pivot table that is not necessarily up-to-date.
Enjoy life, this is not a rehearsal !!!
-
Imagine the following interactive mathematical application: - the data loaded in the application is split in two different 'types' - the first type, let's call it the 'interactive' side of the application, contains data that is manipulated (added, deleted, changed, ...) by the user. It's effect on other data can be immediately calculated and we can quite easily determine which parts of the screen needs to be redrawn to make the screen back consistent - the second type, let's call it the 'constraint' side of the application, contains data that is less frequently manipulated by the user. But if it is manipulated, it could have an impact on any element of the 'interactive' side. The problem is that there is no one-to-one relation between elements in the 'constraints' side and elements in the 'interactive' side. If we want to show the user an always-up-to-date 'interactive' view, certain complex calculations are needed which can easily take up several minutes. My current approach is to disable the 'interactive' side from the moment anything is changed on the 'constraint' side. The user can then continue to work on the 'constraint' side, but if he wants to go back to the 'interactive' side of the application, he will have to perform a full recalculation. Result: a slow, but always consistent application (regarding the 'interactive' side). The alternative could be to keep the 'interactive' side enabled while the user is changing elements in the 'constraint' side. Often the user can know what the impact is of his changes on the 'interactive' side and simply pressing F5 on the correct cell in the interactive grid can then calculate the effects from the 'constraint' side to that specific cell of the 'interactive' side. Result: a faster, but not always consistent application, meaning the user could draw conclusions from incorrect values. Does anyone of you have an application with a similar problem (choosing between slow and consistent or fast and inconsistent)? Any tips on how to have a fast(er) application with still having a quite good data consistency in the 'interactive' side? Thanks in advance for your tips.
Enjoy life, this is not a rehearsal !!!
You need to identify the dependencies between data elements in the interactive side and elements in the constraint side. Then when a constraint element is changed, you only update the interactive-side data which is dependent on it. This structure has been studied in Artificial Intelligence for some time. The main references are: Doyle, J., "A Truth Maintenance System," Artificial Intelligence 12 (1979) 231-272. de Kleer, J., "An Assumption-Based TMS," Artificial Intelligence 28 (1986), 127-162.