On 3/6/06, adak <[EMAIL PROTECTED]> wrote: > YOU ARE PERFECTLY CORRECT - BUT ONLY FOR THE ** FIRST ** indexing of > the record. After the record has been properly indexed, the queries are > MUCH FASTER than ANY algorithmic solution - because in a sense, the > answer is already available - it's "precomputed", almost.
well, don't teach us what does precomputation mean, we talked about this argument many times in the last few weeks in this list ...:) Anyway, my point was another one: the problem is a 0-1 Knapsack, if you say: "ok, using indices we can do precomputations" it's ok for me, precompute everything you want with indices, partial tables, views, materialized views and-so-on, but the problem is and will always be a 0-1 knapsack, I just wanted to stress on this: someone said "it's a knapsack" and you answered: "no, mad boy, you have indices to use as precomputation !" ... it doesn't make any sense ... IMHO the problem is a 0-1 knapsack, the implementation of the specific solution of this problem using a database requires more and more details: table structures, available indices, views and materialized views and-so-on, obviously if there are indices to use to directly access one or a set of records faster than using sequential scan; the problem solver MUST use these instruments, but this doesn't change the problem behind: this is a 0-1 knapsack problem, solve it in the way you prefer, but it still remains the very same problem with his own complexity long discussed in literature. Greetings. Mattia Merzi. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to algogeeks@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/algogeeks -~----------~----~----~----~------~----~------~--~---
