Paradox Community

Items in pnews.paradox-programming

Subject:Re: Need Advice on Secondary Indices
Date:Thu, 19 Apr 2018 11:36:20 -0700
From:Peter <peter@whiteknight.email>
Newsgroups:pnews.paradox-programming
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.

Peter


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" 
> table.
> 
> 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.
> 
> Jure
> 
> 
> "Peter"  je napisal v sporočilo news:5ad7a533$1@pnews.thedbcommunity.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.
> 
> Peter


Copyright © 2004 thedbcommunity.com