Subject | Re: [IBO] master-detail relation with SP |
---|---|
Author | Helen Borrie |
Post date | 2003-12-01T14:10:29Z |
At 03:39 PM 1/12/2003 +0100, you wrote:
only those three columns in your "selector" dataset, the scrolling
interface on thousands of records will be terrible. Forget a scrolling
interface for all but selector sets of up to 200 records. It is NOT good
client/server design and it's bad for users' eyesight and stress-levels too.
Focus on the "drill-down" searching interface to capture unique or
small-set attributes from the user. You can do imaginative things with
non-data-aware controls to achieve a "point-and-click" interface without
live scrolling datasets. Use grids to display small sets. Short visits to
the server for single rows or small sets are an exponentially lower load on
network and client resources than passing huge sets across the wire.
Hmmm, gotta go to bed now...
Helen
>When it is advised to use views and when selectable stored procedures?Of course views can have params!! They are just like tables in this respect.
>views can't have params ;)
>In my case there is table, which will grow in future (thoudsand's ofThis is certainly not a good approach for a large table. Even if you have
>records), so I select at first only ID, name & surname. Then there is a
>need to edit such record, M/D relationship is used (however, scrolling in
>grid is slow then there is M/D relationship)
only those three columns in your "selector" dataset, the scrolling
interface on thousands of records will be terrible. Forget a scrolling
interface for all but selector sets of up to 200 records. It is NOT good
client/server design and it's bad for users' eyesight and stress-levels too.
Focus on the "drill-down" searching interface to capture unique or
small-set attributes from the user. You can do imaginative things with
non-data-aware controls to achieve a "point-and-click" interface without
live scrolling datasets. Use grids to display small sets. Short visits to
the server for single rows or small sets are an exponentially lower load on
network and client resources than passing huge sets across the wire.
Hmmm, gotta go to bed now...
Helen
>At 2003-11-30 23:46, you wrote:
> >Still, implementing a M/d relationship between a table and itself (without
> >a self-referencing F/K structure) is liable to cause weird updating
> >problems whichever way you go, since you're updating the same record
> >simultaneously from two datasets. I'd be questioning why you are doing
> this.
>
>
>
> --/ Gediminas /--
>The Truth Is Out There
>
>
>
>___________________________________________________________________________
>IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
>___________________________________________________________________________
>http://www.ibobjects.com - your IBO community resource for Tech Info papers,
>keyword-searchable FAQ, community code contributions and more !
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/