Вот через JQuery http://www.xiper.net/collect/html-and-css-tricks/verstka-form/nice-select-jquery.html , через css я тоже как и nomads не слышал.
Сейчас понял, что возможно не до конца понял задачу. Данные будут доставаться только по prop_x и их комбинациям, и в запросах в where не будет поиска по id, или же сортировки по id? Если не будет, то тогда будем думать вариант другой.
В любом случае, я думаю в основной таблице будут значения text, если это так, то данные которые будут сортироваться часто лучше вынести в отдельную таблицу, чтобы таблица с текстами лишний раз не трогалась.
Насчёт одного запроса или несколько... Два запроса - это не обязательно хуже одного. Часто бывает, что для облегчения нагрузки запросы лучше разбить на два. Но нужно смотреть на конкретную задачу.
Но идёт к тому http://blogs.computerra.ru/4183
неправда, им всё равно кого поиметь.
Молитесь богам адсенса, чтобы и дальше был такой расклад :) Через несколько недель может уменьшиться.
Архивариус, то что она не считалась я заметил, но по рассчётам сумма вышла больше чем ожидалась :)
Это ещё нужно учесть, что на кликабельные места я адсенс повесил (понятно что он принёс больше), а в конце месяца на часть места, куда переместил бегун, я повесил тизеры ведущие на свой проект.
Базы данных - это не обязательно SQL-базы данных. Поэтому замечание Brand from Amber справедливо.
но чем больше мы удаляемся в сторону постройки кастомной файловой системы, тем ближе мы приближаемся к эффективности использования уже готовых решений, ибо начинают играть роль вопросы тестирования и.т.д.
И для большинства случаев проще использовать что-то готовое, чем городить нечто своё, и это вполне может какая-то реляционная база, которая может быть в чём-то теряет, но для подавляющего большинства решений имеет свои преимущества в плане выборок и универсальности настроек.
Хотя и любое свое решение имеет право на жизнь. Например, сейчас мне пишут систему, которая будет работать на связке MySQL+MongoDB - основные данные будет хранится в MySQL и работа с ними будет проводить через ORM, и похожий но со своими особенностями слой будет лежать над MongoDB, но в этой NoSQL базе будут хранится дополнительные поля для материалов и разделов.
Первоначально хотели делать используя паттерн EAV, но моя настороженность и мнение программиста всё же объединились вместе и мы пришли к выводу, что это будет не совсем рациональный подход. С другой стороны минусом NoSQL (в частности MongoDB) есть средняя отказоустойчивость и время для восстановления после сбоев. В итоге, сошлись, что основные данные храним в MySQL и если MongoDB в дауне или же идёт процесс восстановления данных, то соответствующие данные просто не учитываются при поиске и не отображаются.
Сейчас должна выйти новая версия MongoDB и там будет журналирование, но пока что полного доверия нет, поэтому остановились на этой схеме.
не факт и не всегда.
Индексы в базах, тоже какбы не спроста придуманы. И зачастую фнукция написанная на сях будет быстрее работать чем та же, на пхп.
У меня за вторую половину декабря доходность возросла на сайте в 10 раз (по балансу, по финансовой статистике осталось всё как нужно). Стучался в поддержку - толком ничего сказали. После получения денег - написал в асю опять. Там мне сказали, что всё ок - это просто досчитали за прошлые несколько месяцев.
Вышел такой себе новогодний подарок. :)
