Użytkownik Paul McNett napisał: > The user clicks the arrow to move to the next record, which results in the > main > bizobj going to the next record, which results in 10 child bizobjs being > requeried, > which results in 15 grandchild bizobjs being requeried, and down the line > even to a > couple great-great-great grandchild bizobjs. > > This makes browsing the main records quickly unbearable. > > All my change should have done is add 250ms to that process when clicking to > the next > record, but lightning-fast response to quickly navigate to 10 or 20 records > away by > repeatedly clicking the next arrow.
It looks your data aren't optimally organized ;). I have opposite experiences. My example data consist of 12 tables with maximum width 3 and total chain size 4 nodes. I use PostgreSQL backend. Maximum total fetch size is 200 rows, while average is 20 rows. Since data are rare changed I use cache interval 10 min and I have 22 data controls on data page. Over the LAN link I have timings ([ms] min/avg/max): - unbuffered fetch: 13/25/82 - buffered fetch: 1/1/1 - update: 59/64/74. Fetching is cheaper than updating, isn't it? Over the slow ADSL link, timings are ([ms] min/avg/max): - unbuffered fetch: 474/730/1750 - buffered fetch: 1/1/1 - update: 57/69/83. Now, update takes loooong time. Since data are highly normalized, delaying fetches of child data is the worst idea of all possible. Can I tell to the user: here are the part of your data, within 1 s you get the rest of them? Rather not. The most sensible way is to deliver it delayed but all and complete the same time. There is also no sense to add extra 100 ms delay to 70 ms update time. However, if you have large flat child tables with large amount of binary data, then your approach fits better. But why instead doing such magic in UI layer, don't you simply use RequeryWithParent property? Then you will achieve quick response time on branch access as well. -- Regards Jacek Kałucki _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
