Добавьте поле, в которое вносите название с вырезанными пробелами и т.д
Например
KV-Y53A1==>kvy53a1
Sk-2==>sk2
И т.д. Тогда юзер вводит KV Y53A1 мы переводим в нижний регистр и вырезаем пробелы и получаем KV Y53A1==>kvy53a1.
Никто про сохранение и не говорил.
Я представляю рядового юзера который с легкостью роется в функциях шифрования md5 или aes256...
А рядовому юзеру и не важно какие функции шифрования используются. А не рядовой посмотрит!
Я не спора ради. Я просто к тому, что согласен я, "что можно сделать на клиенте, надо там и делать", но все же есть определенный предел... . А если потом на сервере снова хэшировать уже хэш, то тогда смысл первоначального хэша.
Все что можно делать на стороне клиента нужно делать на стороне клиента.
Замечательно. Я всегда думал, что голый пароль сохранять нельзя, надо добавлять соль?!
Заходим на сайт, открываем fierbug и все вся схема хэширования пароля прямо на ладони.
'key1'=>array('index1'=>array('тут не важно что'),
'index2'=>array('тут не важно что'),
'index3'=>array('тут не важно что')),
'key2'=>array('index1'=>array('тут не важно что'),
'index4'=>array('тут не важно что'),
'index2'=>array('тут не важно что')),
'key3'=>array('index1'=>array('тут не важно что'),
'index8'=>array('тут не важно что'),
'index2'=>array('тут не важно что'))
);
Как можно получить пересекающиеся значения ключей. В данном случае на выходе надо получить index1 и index2. Количество элементов в массиве $arr не ограничено.
Не там Вы пытаетесь оптимизировать.
У Вас допустим 1000 новостей к каждой новости по 30 комментариев. Если у Вас нет запроса выводящего все новости с суммированными комментами, тогда зачем заводить лишнее поле, плюс поддерживать целостность данных--> лишние усилия. Мы уже выяснили, что нагрузка при подсчете минимальна.(не читаем таблицу, а смотрим дерево индекса.) Не надо мещать MySQL. Тем более я уж не говорю про КЭШ MySQL
Возникла еще одна проблема которую не могу одолеть..
INSERT INTO table1 (col1,col2) VALUES ((SELECT FROM1),(SELECT FROM2)); т.е нужна множественная вставка в таблицу 2-х колумнов из других таблиц, в выдаче ответа пока не нашел.
Заранее спасибо.
Вы читаете ответы, пытаетесь их проверить? Ваш индекс по полю post нужен обязательно. Но он не даст using index в EXPLAIN.
P.S Можно еще сделать так. Добавить полу count_post в основную таблицу. А на таблицу с постами повесить три триггера. ИМХО, нет здесь смысла делать VIEW
#Вот тут то меня и "развило", я знал, что есть такая штука как EXPLAIN
EXPLAIN
SELECT t1.`id`, COUNT(t2.`id`)
FROM`table1`AS t1 LEFTJOIN`table2`AS t2 ON t1.`id`=t2.`parent`
WHERE t1.`id`=1 GROUPBY t1.`id`;
И вот я и до развивался.
Что я увидел. А то что Вам и говорил в столбик rows для первой таблицы просмотрено 1 строка, EXTRA пустое(вернее здесь показывает using index, но у вас так не получится). По второй смотрится rows--> 7 строк, EXTRA пустое.
Но потом я еще решил "развиться" и вспомнил, что если в графе EXTRA будет указан using index
то таблица вообще не читается, а смотрится только index. Как этого добиться я оставляю на Ваше развитие. (у меня получилось ).
P.S А так я Вам просто советую Вы сначала проверьте что Вам говорят, а уже потом говорите что и кому надо делать.