| Subject | Re: [firebird-support] Re: Store Sum Value in Table |
|---|---|
| Author | The Wogster |
| Post date | 2006-04-01T14:15:23Z |
Ivan Setya Darmawan wrote:
not the data fit the UI.
Right now, the Treeview may be the majority of the application, but 5
years down the road, the application may have changed considerably. It
may have changed to a point where the Treeview may be a very small part
of the process, or eliminated completely. Of course at that point you
need to change the data, much harder to do, then to change the UI.
One possibility is an array, you keep a couple of pointer values, one
for the major category, one for the minor category, and one for the
current position. As you read the database, you add items to the array
adding them to total variables, when you change categories you update
the total array value, reset the pointer and total variable. When your
done, you update the UI using the array, rather then the database.
Unless your table has millions of values in it (accounts are usually
limited to a few hundred, it can run through just about as fast as the
UI update can.
Second possibility, create a union to combine the values, one part being
the major total, another the minor total and another being the value, in
the case of the totals, they use group-by and sum to get the actual
values from the data table. Not sure if unions can use views, or views
unions, but a view of a union that combines views of each portion makes
updating the UI very easy, in that it simply reads the final view.
W
> --- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:I think what Helen is trying to say, is that the UI should fit the data,
>
> very enlightning, thx again.
>
>> That is generally more robust, since your design makes referential
>> integrity more complex. A treeview is not a database structure, it
>> is a user interface. A database *stores* data. It does not (and
>> should not) dictate to the user interface; and the user interface
>> equally should not dictate the database structure.
>>
>> The "Q" in "SQL" means "query". The whole concept of a query
>> language is that you can generate output, via SQL, in any structure
>> that your user interface demands, including flattened structures such
>> as you have set up to "fit the shape" of your treeview UI.
>
> wow..woo.. just a simple chat and you almost can see all my
> implementation. My Treeview implementation that cover almost 80% of
> the application do really dictate my database structure. I will be
> back with actual modified table structure and any SQL involved
> later..so this will not bear to OOT.
not the data fit the UI.
Right now, the Treeview may be the majority of the application, but 5
years down the road, the application may have changed considerably. It
may have changed to a point where the Treeview may be a very small part
of the process, or eliminated completely. Of course at that point you
need to change the data, much harder to do, then to change the UI.
One possibility is an array, you keep a couple of pointer values, one
for the major category, one for the minor category, and one for the
current position. As you read the database, you add items to the array
adding them to total variables, when you change categories you update
the total array value, reset the pointer and total variable. When your
done, you update the UI using the array, rather then the database.
Unless your table has millions of values in it (accounts are usually
limited to a few hundred, it can run through just about as fast as the
UI update can.
Second possibility, create a union to combine the values, one part being
the major total, another the minor total and another being the value, in
the case of the totals, they use group-by and sum to get the actual
values from the data table. Not sure if unions can use views, or views
unions, but a view of a union that combines views of each portion makes
updating the UI very easy, in that it simply reads the final view.
W