| Subject | Re: [ib-support] Case insensitive order by? |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-01-23T01:07:09Z |
At 04:55 PM 22-01-02 -0700, you wrote:
With client/server the grid does have a role for display multiple columns from an output set. But, whether you're using query or table objects, all are queries. The spreadsheet approach (TTable) is met by SELECT * FROM ATABLE with no restricting or ordering capability other than, respectively, to apply client-side filters and to borrow index definitions from the database. Quite apart from the traffic and the memory overhead of maxing the buffers, you have the matter of holding these browsable datasets in an open transaction for uncontrollably long periods, thus preventing the database from doing its housecleaning.
The client/server approach is meant to be fulfilled by queries, viz. SELECT <columns you need> WHERE <restricted criteria>. Delphi supports parameterised queries so there is never any need to have vast numbers of rows parked in the client buffers. C/S UIs should be about supplying the means for users to select parameters and fire off queries that return the exact dataset they want.
So, instead of scrolling through 120,000 rows looking for Smith, Albert of Blake St, SomeTown, an interface should have them typing in enough characters to provide parameters for fetching a suitable dataset for pinpointing the sought row (ideally, a single row, but you can live with a small dataset of Smiths).
btw, I think (from my experience, at least) that the need to imitate previous software is about the worst requirement you could have to work with, ESPECIALLY if the system is moving from a file-based DB backend to client/server. When you're building new on top of old, time spent working with users on prototyping efficient user interfaces is money in the rainy-day account. It pays HIGH interest.
I've always been interested to survey users about why they think they want scrolling browser-style interfaces (and I always do, because I have this malicious streak!). You don't have to scratch very deep to discover that it's because they almost invariably perceive that "that's how computers work". That's the "intuitive" that you mention - it's all they have ever been offered.
Helen
All for Open and Open for All
Firebird Open SQL Database ยท http://firebirdsql.org
_______________________________________________________
>To clarify, the actual control being used is a DBgrid (Straight DelphiIt makes sense if you are interrogating a local database - people tend to design desktop database apps like spreadsheets and offer a browsing interface. The BDE and TDBGrid reflects those requirements...why not? the BDE is Paradox. There's a whole industry out there of component companies making ever cuter browsing interfaces. The cuter the grids get, the more the lemming consumers become convinced that browsing interfaces are RIGHT.
>TDBGrid), with two columns in the grid (3 columns are being selected from
>the database, the two being displayed, and the PK of the record).
>
>> Table-oriented GUIs applications are slow on client/server databases, even
>quite small ones.
>
>Actually, we haven't had many issues up until now.
>However, no one around here could think of a more intuitive (From a dumb
>user's point of view, which is what we have to deal with) way of displaying
>result sets from a query, other than a grid type of control (Given that
>multiple columns need to be shown). Grid's are more of a dataset type of
>gui control, rather than a table-type.
With client/server the grid does have a role for display multiple columns from an output set. But, whether you're using query or table objects, all are queries. The spreadsheet approach (TTable) is met by SELECT * FROM ATABLE with no restricting or ordering capability other than, respectively, to apply client-side filters and to borrow index definitions from the database. Quite apart from the traffic and the memory overhead of maxing the buffers, you have the matter of holding these browsable datasets in an open transaction for uncontrollably long periods, thus preventing the database from doing its housecleaning.
The client/server approach is meant to be fulfilled by queries, viz. SELECT <columns you need> WHERE <restricted criteria>. Delphi supports parameterised queries so there is never any need to have vast numbers of rows parked in the client buffers. C/S UIs should be about supplying the means for users to select parameters and fire off queries that return the exact dataset they want.
So, instead of scrolling through 120,000 rows looking for Smith, Albert of Blake St, SomeTown, an interface should have them typing in enough characters to provide parameters for fetching a suitable dataset for pinpointing the sought row (ideally, a single row, but you can live with a small dataset of Smiths).
btw, I think (from my experience, at least) that the need to imitate previous software is about the worst requirement you could have to work with, ESPECIALLY if the system is moving from a file-based DB backend to client/server. When you're building new on top of old, time spent working with users on prototyping efficient user interfaces is money in the rainy-day account. It pays HIGH interest.
I've always been interested to survey users about why they think they want scrolling browser-style interfaces (and I always do, because I have this malicious streak!). You don't have to scratch very deep to discover that it's because they almost invariably perceive that "that's how computers work". That's the "intuitive" that you mention - it's all they have ever been offered.
>It would have been fun to do the research, but right now, not enough time...that old IT project management crusty "We don't have time to stop for gas." :)
>(How many times have people said that before? :)).
>Ah well, sounds like it's time to write some triggers.Life is full of compromise.
Helen
All for Open and Open for All
Firebird Open SQL Database ยท http://firebirdsql.org
_______________________________________________________