LiveStreet CMS

Да причем здесь пальцы. И меренье писю… ми.
Идея и стратегию юзабилити. Да и windows 7- м на планншете можно пользоваться. Но все признают, что их продажи по сравнению с Android и iOS платформами горзадо меньше. Поэтому MS и разработала в спешном порядке Windows 8, где добавила интерфейс metro, заточенный именно под планшеты и смартфоны.

Ну что вы мыслите как-то бедно и сиюминутно. Перед тем как нажать «ответить» подумайте хорошо и проанализируйте.

Всё надо делать с умом ;)

Ну ёт. Можно! Но удобно ли постоянно увеличивать?
Конкретика. Я написал: изучаем интерфейс wp7, w8.
Лучшие берем. Не спешите с ответом и ухмылками, просто подумайте.
P.S. подумайте информерами и блоками ;)

Я не говорю не подходит.
Я говорю с точки зрения юзабилити неудобно. Вы попробуйте мужским пальцем попасть на мелкие ссылки.
P.S. Как подсказка. Интерфейс metro (WP7, W8). Что называется — ищите там. На мой взгляд — там с юзабилити всё в порядке (на планшетах)

А так как черз год у каждого второго он будет (кто пользуется и-нетом) — то сами понимаете какой интерфейс должен быть.

Дизайн — это вторичное. Главное юзабилити в первую очередь. Дизайнер — это технолог с хорошим вкусом.

Уже что-то, но попробуйте еще лучше заточить юзабилити под планшеты и смартфоны.
P.S. Подсказка: обратите внимание на интерфейс metro (wp7, win8) и nulf из этого дизайна может что-то получиться путное

Напишу тоже, что и всем:
Вы знаете, все аккуратненько и нормальненько, но. Это прошлый век.
Как пользоваться этим дизайнов на планшете? Вы подумали?
В свете развития и популярности планшетов и смартфонов, с точки зрения юзабилити данный дизайн не подходит.
MS не зря долго облизывает интерфейс metro.

Дизайнер в первую очередь — это технолог. (с хорошим вкусом) :)

Вы знаете, все аккуратненько и нормальненько, но. Это прошлый век.
Как пользоваться этим дизайнов на планшете? Вы подумали?
В свете развития и популярности планшетов и смартфонов, с точки зрения юзабилити данный дизайн не подходит

Далее, в подзапросе order by и limit? Зачем?
Это один тормоз + шанс потеряться оптимизатору.

Вы все делаете для того чтобы оптимизатор послал вас очень далеко и перебирал всю таблицу

Далее, искоренить все OR и IN, особенно когда много OR и в IN «много», из этого и «теряется»? часто, оптимизатор

Короче, везде, где NULL и ALL или filesort или temp это плохо :)
в двух словах

Это значит что перебирается вся таблица.

Оптимизатор пытался выискать оптимальный индекс, но не один не попал под условия выборки, значит запрос составлен неверно или индекс. :\
Да и посмотрите на derived там тоже null :\
Наследованная таблица select — null индекс :\

Вы посмотрите на этот запрос. Сколько подзапросов и join-ов!
Причем не использующих индексов. Надеимся на кеш ;)?
C такими запросами можно только альфу выпускать

Смотрим авторизированным, и особенно explain

<code>SELECT t_fast . * , tc . * , u.user_login AS user_login,
IF (
tv.topic_id IS NULL , 0, 1
) AS user_is_vote, tv.vote_delta AS user_vote_delta,
IF (
tqv.topic_id IS NULL , 0, 1
) AS user_question_is_vote, bu.is_moderator AS user_is_blog_moderator, bu.is_administrator AS user_is_blog_administrator,
IF (
tr.comment_count_last IS NULL , t_fast.topic_count_comment, t_fast.topic_count_comment - tr.comment_count_last
) AS count_comment_new
FROM (

SELECT t . * , b.blog_title AS blog_title, b.blog_type AS blog_type, b.blog_url AS blog_url, b.user_owner_id AS blog_owner_id
FROM prefix_topic AS t, prefix_blog AS b
WHERE 1 =1
AND t.topic_publish =1
AND (
t.topic_rating >=8
OR topic_publish_index =1
)
AND b.blog_type
IN (
'personal', 'open'
)
AND t.blog_id = b.blog_id
ORDER BY t.topic_date_add DESC
LIMIT 0 , 10
) AS t_fast
JOIN prefix_user AS u ON t_fast.user_id = u.user_id
LEFT JOIN (

SELECT topic_id, vote_delta
FROM prefix_topic_vote
WHERE user_voter_id =1
) AS tv ON t_fast.topic_id = tv.topic_id
LEFT JOIN (

SELECT topic_id, comment_count_last
FROM prefix_topic_read
WHERE user_id =1
) AS tr ON t_fast.topic_id = tr.topic_id
LEFT JOIN (

SELECT topic_id
FROM prefix_topic_question_vote
WHERE user_voter_id =1
) AS tqv ON t_fast.topic_id = tqv.topic_id
LEFT JOIN (

SELECT is_moderator, is_administrator, blog_id
FROM prefix_blog_user
WHERE user_id =1
) AS bu ON t_fast.blog_id = bu.blog_id
JOIN prefix_topic_content AS tc ON t_fast.topic_id = tc.topic_id</code>

а вот explain этого запроса!

<code>id  	 select_type  	 table  	 type  	 possible_keys  	 key  	 key_len  	 ref  	 rows  	 Extra
1 	PRIMARY 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	Impossible WHERE noticed after reading const table...
6 	DERIVED 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	no matching row in const table
5 	DERIVED 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	no matching row in const table
4 	DERIVED 	prefix_topic_read 	ref 	user_id 	user_id 	4 	  	1 	 
3 	DERIVED 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	no matching row in const table
2 	DERIVED 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	NULL 	Impossible WHERE noticed after reading const table...</code>

Вы мне ответьте, а «где» индексы !?

На сколько я вижу, у вас подзапросы и при авторизированном пользователе сохраняются

<code>JOIN prefix_user AS u ON t_fast.user_id=u.user_id
				LEFT JOIN (
						SELECT
							topic_id,
							vote_delta</code>

Про индексы?
Я привел explain запроса. Запрос не брал совсем индексов, это правильно? ;)

id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
6 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
5 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
4 DERIVED prefix_topic_read ref user_id user_id 4 1 Using where
3 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
2 DERIVED NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…

Не видно пока.
Возьмите для начала все свои запросы explain-ом проверьте ;)
Я уже вверху писал, как можно сделать запрос не использующий совсем индексы?
Вы мне ответите? Это работа? Это знание узкого места? Я наверно резковато, но я знаю о чем говорю. Разработчику главнее конструктивная критика а не дифирамбы…

Спасибо у меня свой проект есть :) 95% готовности.

Не обсуждаемо — не годятся и все, поверьте пока на слово :)

В блогах разработчиков MySQL, под рукой к сожалению нет.
Они очень хорошо описывают работу оптимизаторов и т.п. Если проблем с анг. языком нет — через неделю вы будите почти асом в оптимизациях, а после реальных тестов, где-то через пару месяцев — гуру ;)