Re^2: how do hashes work - complexity question

well, i now that with indexing the db data i can speed up my work. but then :

1.i have to index the big table that is already indexed (the value itself is an index), and that is an extra number of steps

2. i have to import my data (big table) - that is an extra number of steps,

3.i have to index more that one column to speed up the search - that is a redundant number of steps.

so the point is why to do all that if i can do it only by hashing(importing) smaller data and then just sweep once through the big data(file).

plus what i notice is, that when db engine is importing staff, it is formatting it in some manner and that has to be expensive (extra number of steps) with respect to sweeping through already formatted file (format is not the issue, switching the formats is ).

so the question was, when calculating theoretical complexity of hashed data, can i neglect the fact that, for every checkup, it has to go through all hash keys to get me the value for my checkup (is it, should i put it 'legite', to do that). because that is what i'm actually doing when evaluating the complexity of my db query, isn't it?

thank you for your fast reply!

Comment on Re^2: how do hashes work - complexity question

Replies are listed 'Best First'.
Re^3: how do hashes work - complexity question by zwon (Abbot) on Jul 11, 2009 at 11:37 UTC
so the question was, when calculating theoretical complexity of hashed data, can i neglect the fact that, for every checkup, it has to go through all hash keys to get me the value for my checkup There's no need to go through all hash keys, you're directly accessing element you're need (it's practically O(1) operation), so yes you're calculations are correct. Note, that the same is true for accessing DB record using index	[reply]
Re^3: how do hashes work - complexity question by Anonymous Monk on Jul 11, 2009 at 10:06 UTC
Isn't it easier/shorter to write SQL query than to write complicated hash perl?	[reply]