|Subject:||Re: Need Advice on Secondary Indices
|Date:||Thu, 19 Apr 2018 11:36:20 -0700
Yup, I plan on having a table for archives so the table I am concerned
about would be for active tickets. There will be about 20 fields and
maybe 10 users so perhaps I shouldn't worry about it, just seems like a
brute force approach.
On 04/19/2018 12:46 AM, modridirkac wrote:
> Or even have two tables, one for "active" cases, one for "closed" tickets.
> "Active" table should be small, adn can have more indexes than "closed"
> If you are really worried about coruption, then your forms should
> display/edit data from :PRIV: tables.
> I have one biiiig table (150MB) with 90000+ records, 70 columns, used by
> 20+ users daily,
> data is displayed/edited directly on the form (no :PRIV: tables).
> And this table has 12 secondary indexes. 6 on single field, 6 on 2 fields.
> And have "index out of date" maybe once a year.
> "Peter" je napisal v sporočilo news:email@example.com
> I am making a kind of ticketing system. It will require several views
> (setranges) such as viewing tickets assigned to certain individuals or
> everybody, open/close tickets, by due date or priority and many more.
> The easiest thing is to just define all the secondary indices that are
> required. The problem is that I worry about corruption.
> As an alternative I was thinking of having multiple tables with a few SI
> each and keep them in sync. On the form the user would click the view
> they want and the fields would be redefined to reflect the table with
> the required SI. That sounds like a headache.
> I am interested in hearing about other possibilities. Thanks.