Решение:
MySQL оптимизирует обращение к индексу. Основное требование — наличие крайнего левого компонента.
Т.е. если есть индекс field1, field2, field3, то в любом запросе главное, чтобы присутствовал первый компонент, а остальные, промежуточные компоненты, не используемые в текущем запросе, могут отсутствовать, лишь бы не нарушился порядок следования компонентов
Спасибо, сфинкс используем в других проектах.
Но сейчас вопрос — классическая реализация задачи. Записей до 10000 если наберется за пару лет — будет хорошо, так что записей мало. Но поиск сейчас жутко тормознутый — запросы до 80ms на продакшене, в то время как практически все остальные страницы с трудом за 50ms переваливают.
Версаю аналогично использованию namespace
т.е. все стили описаны согласно макету с описанием полной или частичной вложенности элементов в зависимости от обстоятельств
Идентификаторы использую только глобально.
Идентификаторы элементов форм использую с префиксом идентификатора формы
Не стоит делать поспешные выводы о прикладном назначении. В любом случае вопрос абсолютно не об этом и описан абстрагировано от области применения, т.к. она как бы не влияет на решение.
Вы говорите, даже не вникнув задачу — необходим одновременный поиск по нескольким параметрам
Хранить все поля в одной таблице — плохое решение, оно может быть применимо лишь к объектам с динамическим количеством полей. У меня же их заранее известное статическое количество, так что калечить систему нет надобности, а сделать ее быстрее — нужно. Остается вопрос — как правильнее? (с возможностью масштабирования в последствии — вдруг заказчик добавит пару критериев)
Да уж, на самом деле по скорости и объему оба варианта оказываются похожими — попробовал собрать небольшое приложение. Вопрос уже скорее становится о платформо-независимом коде. А кончную релизацию на базе этого кода можно лепить как угодно
UPD: Первоначальная цель — найти платформу, на которой малой кровью можно охватить win, nix, android и iOS, т.е. реализовать прикладной уровень одним кодом, а системный и визуализацию уже персонально на платформу.
Сейчас кажется решением — java for android, win, nix, obj-c под iOS
Хотя можно попытаться на c все исполнить, но как-то страшно, с cи опыт минимальный и тот под avr-контроллеры
на больших объемах спасают консольные — самый зачетный wkhtmltopdf — у него есть сборки и под винду и пол линукс, так что всем подойдет :)
мои замеры для сложного 3-х страничного html-документа весом ~80кб + несколько растровых изображений в нем:
1. htmlToPdf — 30 секунд, размер файла 900кБ — быстрее всего подогнал шаблон кроссбраузерно + pdf
2. wkhtmltopdf — 0.1 секунда, размер файла 105кБ — супер скорость
3. mPDF — 2 секунды, размер файла 120кБ — оптимальный вариант
с удовольствием бы остановился на wkhtmltopdf — но огромный минус — не поддерживает UTF-8
кроме этих утилит было рассмотрено еще с десяток — но эти так сказать «наименее сырые»
добавлю — full кросс-платформа + куча плюшек (файлы, схемы, шара), бесплатно что-то около 60 Мб дают, за деньги можно расшириться