как заменить известный по счету символ в строке
- Автор темы cbat
- Дата начала
ForJest
- свежая кровь
cbat
Очень сильно решение зависит от размера таблицы.
Если там до 1-5к записей то твоё решение вполне с like достойное.
Единственно что поле INT и запрос типа
WHERE code && 23 будет выполнятся быстрее, т.к. нужно выполнить всего одну операцию, к тому же математическую, с чем процессор справляется лучше.
23 это 10111.
------------------
Решение с введением кучи индексов не кажется мне здравым.
Если записей в таблице очень много, лучше создать отдельную таблицу для каждого признака и там хранить вхождение или не вхождение каждой записи о телефоне.
chisto_tolyan
Т.к. ты видимо хорошо разбираешься в индексах, ты не подскажешь часом - если ли в MySQL ограничения на количество индексов в одной таблице и на количество полей в одном индексе?
Очень сильно решение зависит от размера таблицы.
Если там до 1-5к записей то твоё решение вполне с like достойное.
Единственно что поле INT и запрос типа
WHERE code && 23 будет выполнятся быстрее, т.к. нужно выполнить всего одну операцию, к тому же математическую, с чем процессор справляется лучше.
23 это 10111.
------------------
Решение с введением кучи индексов не кажется мне здравым.
Если записей в таблице очень много, лучше создать отдельную таблицу для каждого признака и там хранить вхождение или не вхождение каждой записи о телефоне.
chisto_tolyan
Т.к. ты видимо хорошо разбираешься в индексах, ты не подскажешь часом - если ли в MySQL ограничения на количество индексов в одной таблице и на количество полей в одном индексе?
ForJest
- свежая кровь
cbat
Если СУБД MySQL, то
Если таблица маленькая, просто сделай её FIXED форматом и используй _любое_ решение которое придёт тебе в голову.
Потому что <1000 строк mysql вполне может держать в кэше.
Если нужна производительность - можешь запихать данные в HEAP таблицу и обращаться уже к ней.
id + признаки, при подсчёте получается
4 + 54 = 58*1000 = 50 килобайт таблица. С производительностью можно даже не заморачиваться, т.к. она целиком влазит в память, с одной стороны и использует индексы для LIKE с другой, т.к. pattern do not starts with wildcard
Если СУБД MySQL, то
Если таблица маленькая, просто сделай её FIXED форматом и используй _любое_ решение которое придёт тебе в голову.
Потому что <1000 строк mysql вполне может держать в кэше.
Если нужна производительность - можешь запихать данные в HEAP таблицу и обращаться уже к ней.
id + признаки, при подсчёте получается
4 + 54 = 58*1000 = 50 килобайт таблица. С производительностью можно даже не заморачиваться, т.к. она целиком влазит в память, с одной стороны и использует индексы для LIKE с другой, т.к. pattern do not starts with wildcard
Yaponchick
Новичок
cbat
SET / Enum
Удобно, но трудно для освоения. =)
SET / Enum
Удобно, но трудно для освоения. =)
Andreika
"PHP for nubies" reader
cbat
а для INT есть двоичная система исчисления (эт почти тоже, что у тебя было изображено в строке), есть в пхп и мускуле операторы/функции, которыми можно проверить включен ли тот ли иной бит и еще много чего... вот тока ссылок на это дело не найду. вероятно потому, что подразумевается, что это знает каждый программер )
а вот мне интересно - что будет, если у тебя добавится новый признак?
а для INT есть двоичная система исчисления (эт почти тоже, что у тебя было изображено в строке), есть в пхп и мускуле операторы/функции, которыми можно проверить включен ли тот ли иной бит и еще много чего... вот тока ссылок на это дело не найду. вероятно потому, что подразумевается, что это знает каждый программер )
а вот мне интересно - что будет, если у тебя добавится новый признак?
cbat
Новичок
это конечно хорошо, но только вот в коде не все значения, как я уже говорил, бинарные.
вот код из моей БД:
1001231... 54 символа
где
1 символ - GSM
2-CDMA
3-WCDMA
4-смартфон
5-тип корпуса
6-тип антенны
... ну понятно в общем
а если надо добавить новый признак в код, то
просто добавляем в конец кода еще одно значение. Кстати, я не все параметры тела храню в коде, например разрешение дисплея и вес в отдельных полях.
-~{}~ 26.02.06 13:10:
Yaponchick
В своем случае я большую ставку делаю не на удобство, а на производительность. На сколько (и будет ли?) производительнее CHAR(54) варианта с использованием SET и ENUM???
Andreika
"PHP for nubies" reader
cbat
это конечно хорошо, но только вот в коде не все значения, как я уже говорил, бинарные.
достать 2 бита не намного сложнее, чем один
просто добавляем в конец кода еще одно значение.
да? чет не помню я что вернет такой запрос ...LIKE '0_(всего53разапо_)' если в таблице теперь будет не 54, а уже 55 символов в поле
это конечно хорошо, но только вот в коде не все значения, как я уже говорил, бинарные.
достать 2 бита не намного сложнее, чем один
просто добавляем в конец кода еще одно значение.
да? чет не помню я что вернет такой запрос ...LIKE '0_(всего53разапо_)' если в таблице теперь будет не 54, а уже 55 символов в поле
cbat
Новичок
не понял. поясни пожалуйста.
Запрос вернет все строки с полем начинающийся с 0! Или я тебя неправильно понял?
Да и еще вопрос:
Сейчас я реализовываю рассширенный поиск по характеристикам сотовых телефонов, собственно для этого и создавался код_признаков.
Чуть подумав, делаю я все это следующим образом:
с формы рассш. поиска данные (54 параметра ) передаются постом скрипту_1 который обработав эти самые данные запускает сессии и формирует код_признаков и сохраняет его в $_SESSION['code']. После чего, скрипт_1 хеадером перебрасывает на другой скрипт_2, который воспользовавшись кодом из $_SESSION['code'] делает выборку в БД и выводит результаты.
Что кто скажет по поводу данного метода???
cbat
Новичок
ForJest
Да, я над этим думал, видимо это пока лучший вариант для кода_признаков! А вот проблему int(64) можно решить разбиением кода на две части для двух полей - хотя можно ли считать это выходом?
Andreika
Запрос ничего не вернет, но это же не проблема! Ведь добавление в поле кода нового признака повлечет изменение и запроса, а т.е.
вместо LIKE '0__'
юзаем LIKE '0___'
Тем более что новые характеристики телефона появляются не так часто!
Да, я над этим думал, видимо это пока лучший вариант для кода_признаков! А вот проблему int(64) можно решить разбиением кода на две части для двух полей - хотя можно ли считать это выходом?
Andreika
Запрос ничего не вернет, но это же не проблема! Ведь добавление в поле кода нового признака повлечет изменение и запроса, а т.е.
вместо LIKE '0__'
юзаем LIKE '0___'
Тем более что новые характеристики телефона появляются не так часто!