My company's product has exactly the features you are discussing
- generic but customizable search form that allows you to specify
criteria for all entity fields, but also for related entities, like
Invoice.Customer.Address.Country == 'Germany'
- also we have generic 'reference fields' for selecting a single
entity, they provide search/autocompletion feature.
And there's a problem with generic lists - usually you are giving your
users too much search options. At first this is great because they can
define their own sophisticated filters but very soon they start using
them as a report tool. And when the amount of data grows the searches
become more and more expensive until they saturate the database. Now
it's hard to optimize it because you would have to add many indexes
for the most-frequently searched columns, which slows down
insert&update, and you usually cannot remove the more costly search
options because users will protest. I'm not saying generic search is
bad, it's great you don't have to develop anything, but if you don't
limit the search options at the beginning you'll be blamed when the
application runs slow. I'd rather give only few search fields (or just
a single one, like in Google) and build database indexes for these
fields.
R
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
