сомневаюсь я что такой индекс тут поможет чем-то.
если бы было WHERE group = 1 AND newsnum = 0 - тогда да.
скорее всего пропадет, т.к. сайт будет пессимизирован из-за черного SEO
табличка pool вида pool_id, option_num, option_name, vote_count
me покупать чтобы багрепорт сделать ? 😮
могу придумать 2 варианта
1) непонимание SQL
2) они не применяют SQL для этих данных, обрабатывают данные на PHP, что, обычно, не очень верно
табличка pool вида pool_id, option_num, vote_count
и все становится не просто, а очень просто
но товарищи выше правильно сказали - какое-то извращение у вас в архитектуре, не sql-ное это дело, стринги разбирать.
Неправду говорят. У асемблера, ООП-языка, SQL и функционального языка общее только одно - программы пишутся латиницей. Да и то не всегда.
В принципе наверное можно такую базу придумать. На практике индексы занимают объем больший чем собственно данные. Не забывайте также о введении новых сущностей как суррогатные первичные ключи или появление в физической модели новых таблиц напр для описания связи много-ко-многим. Не забываем о лог-файлах также
Ну и конечно никто не проводит полную нормализацию, иначе сильные тормоза
iopiop добавил 18.12.2011 в 09:34
ну что вы так.. TC как раз подошел к идее держать метаданные отдельно, вон уже и структурка выделяется потихоньку
Это уже будет второй этап, когда ТС поймет что линейный поиск - это глупо
А дальше, глядишь, и до БД дойдет ☝
у меня на работе БД шесть гиг, причем только цифирьки разные, т.е. по вашей структуре только поля типа 1, 3, 4.
самая большая (из сотни где-то) таблица - 2 млн записей.
и да, это в мире БД это считается небольшой, ничем не примечательной базой.
структура у ТС дерьмо. хранить метаданные вместе данными - зачем? зачем перечитывать постоянно кучу ненужной иннформации? должен быть один файл, в котором поля 1,3,4, а собственно файлы должны лежать либо все по отдельности рядом, либо в одном большом файле (уж не знаю по какой причине). в последнем случае в метафайле добавляется поле в котором записана позиция файла и, для удобства, его длина.
а чтобы поиск быстрый был, нужно к метафайлу индекс построить, какое-нибудь двоичное дерево (быстрее еще ничего не придумали), чтобы не последовательно все читать.
и в результате получаем все ту же базу данных. с одной только разницей что в текущих БД уже все это давно сделано, протестировано и сильно заоптимизировано как на скорость, так и на потребление памяти.
ТС-у - почитать как писался ибей. он тоже сначала был на пхп+файлы. когда количество аукционов достигло 50К, он просто заткнулся. пришлось срочно прикручивать БД. Либо помедитировать на тему "почему фейсбук построен вокруг MySQL, а не на чистых файлах"
и да, не нужно изобретать очередной велосипед
iopiop добавил 17.12.2011 в 22:24
это как, БД их сжимает, что ли? ;-)
на самом деле все с точностью до наоборот, т.к. структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
mod_mem_cache в апаче не используется?
Не только при листинге, любая групповая операция из шелла (типа удаление по маске или установка прав и прочая) будет тормозить и пожирать память сильно потому что сначала строится список всех файлов и только потом к нему применяются действия.
Здесь обсуждалось /ru/forum/665621
Глубокую вложенность тоже делать не стОит т.к. открытие каждого каталога = открытие файла, т.е. если у вас вложенность 10 уровней то для чтения одного файла на самом деле ОС будет делать 11 операций открытия-чтения-закрытия файла
