Здравствуйте, Win32nipuh, Вы писали:

W>Здравствуйте, okon, Вы писали:

O>>Здравствуйте, Win32nipuh, Вы писали:

W>>>Здравствуйте, Don Reba, Вы писали:

DR>>>>Здравствуйте, Win32nipuh, Вы писали:

W>>>>>А смысл это все иметь в памяти?
W>>>>>Почему бы не использовать, например,SQLite ?

DR>>>>Вопрос был о самых быстрых коллекциях, а не о самых медленных.

W>>>так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.

O>>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ?
O>>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?

W>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
W>Подробности не описаны в вопросе ТС.
А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление

Здравствуйте, Win32nipuh, Вы писали:

W>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
W>Подробности не описаны в вопросе ТС.
А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление