так я и делаю сейчас. Но нашему начальству не нравится что на поиск из 150k записей одного штрихкода уходит 0.2 мсек!! фак их мозг, типа с sql быстрее. я и так как мог уже оптимизировал алгоритм

А начальство в ИТ что-нибудь понимает?

В смысле в разработке ПО и алгоритмах? Или очередные «эффективные менеджеры»?

ну так чуть чуть.. да и всеравноне мешалобы, просто на компах по хуже поиск достигается до 1 секунды, и при сканировании товара на кассах, это жутко напрягает кассиров )))

Хм. Тогда следующий вопрос - нафига искать штрих-коды напрямую в дбф? Один раз в сутки проапдейтить 150к записей в базе не так уж и сложно. Просто перед началом рабочего дня делай переливку новой версии прайса в тот-же sqlite или firebird.

ну я в свой формат сейчас так и делаю, держу в памяти, жрет это дело 60 мб озу, много. А как в sqlite все это замутить я не разобрался.. особо не старался правда..

Если ты сейчас в памяти держишь _ВЕСЬ_ этот прайс, то _КАК_ ты ухитрился затормозить поиск по нему что он занимает до секунды?

Ну были такие компы раньше с 600 mhz процом и 128 <pc-133> RAM. Вот они-то черт их побери работают и до сих пор!

кстати в консоле набираю топ и пишет такое:
virt 80m
res 48m
shr 11m
я так понял res это оперативы стока занимает, а virt что такое, это точно не swap.. потомучто used swap у меня 0

Эммм. А ты полным перебором что-ли ищешь нужный штрих-код? Отсортировать массив по штрих-коду и пройтись банальным бинарным поиском по нему не вариант?

штрихкоды символьные

А строки уже не сортируются?

> штрихкоды символьные

кто-то не осилил индексы?

я использую строки и столбцы в которых использую штрихкоды и поиск по наименованию. Все это из одной таблицы ессесно оно связано между собой, так вот каждый раз при поиске заново сортировать то по наименованию , то по штрихкоду вызывает МЕГА тормоза, так что я хз что делать с этим. оставил без сортировки, вроде норм

> заново сортировать то по наименованию , то по штрихкоду

ага, т.е. ты не осилил создание двух индексов для одной таблицы?

о QFile::seek() и QFile::read() я уже говорил. добавлю QHash, для индекса.

нет не осилил.. представь как я найду подстроку «кофе» среди 50000 тысяч строк например? по индексу твоему, я сделал так, сначала сравниваю первую и последнюю букву т.е. if((substr[0]==str[0]) || (substr[4]==str[4])) то тщательное сравнение... код привел образно.. подстрока ищется не во всей строке а только относительно начала строки

не подходит т.к. работа с оп. памятью

> подстрока ищется не во всей строке а только относительно начала строки

с бинарным поиском мы не дружим?

тогда вообще писать программу на qt нет смысла, она ведь в/с озу работать будет. думаю, перфокарты — единственно правильный выбор.

Булочничество.

А опишите пожалуйста поточнее вашу конкретную задачу поиска. Опишите точнее ваши таблицы и мы подумаем, в какие структуры данных их преобразовать, который бы позволили очень быстро искать.

Я не понял, почему не создать 2 индекса. Индекс - это структура данных, оформленная по таким законам, которые делают поиск в ней очень быстрым. Например, бинарное дерево std::map.

Первый индекс - по наименованию товаров. Строку в дереве вы сможете найти за log2(N) шагов. Для 50000000 (вы написали «50000 тысяч» -> 50 млн) строк вы найдёте товар по наименованию максимум за 26 сравнений строк. Если 50 тысяч - 16 сравнений.

Второй индекс - по штрихкоду.

При поступлении новой базы, вы перефигачиваете её в свои структуры и создаёте 2 индекса.

std::map<struct MyStringType, struct ShopThing*> index1;
std::map<struct MyBarCodeType, struct ShopThing*> index2;

struct MyStringType
{
   std::string data_;
   // char* data_;

   // operator< будет вызываться из
   // std::map::find(), std::map::operator[]()
   // std::map::insert()...
   // т.е. он нужен std::map-у для понимания того, какая строка
   // меньше какой.
   bool operator<( const MyStringType& _other )
   {
      // когда мы меньше другого, когда нет.
      return ( strcmp(data_.c_str(), _other.c_str()) < 0 );

   }
};


struct MyBarCodeType
{
   unsigned char barcode[16];
   bool operator<() { ... };
};

На оперативу денег надо попросить у начальников.

на >500 компов с памятью ddr,ddr2,dimm не реально на все поставить

http://blog.vernart.ru/programming/cplusplus/stroki-c-massiv-strok-c/

про скорость map

По приведённой ссылке автор сравнил литры с километрами. Почитайте лучше об устройстве std::map и std::vector, а не блоги школьнегов.

> про скорость map

использовать map для хранения списков - это гениальная идея, аффтор достоин Нобелевки

я почитал мат часть и понял что ссылка приведенная мной, не очень удачна. Множество моих вопросов отпала. Спасибо всем за участие.