SEO-шники давно уже обозлились на Продвижение за то что Продвижение рассказала всем клиентам как ранжировать ссылками и прочее что клиенты вполне сами могут сделать. Тем самым раскрыв глаза клиентам, что с них дерут деньги не за что. Так что я давно не воспринимаю информацию от них (SEO-шников) как достоверную.
Если Продвижение такое плохое то почему они так интенсивно расширяются и количество клиентов у них давно за тысячу?
Кстати, человек, написавший статью о том как его увольняли, состоит на учете в псих диспансере (хотя по тексту это становится очевидным), так что это тоже не источник.
Не уподобляйтесь западной прессе освещающей Южно Осетинский конфликт :) Надо смотреть с разных сторон.
Что уж сказать. Это будет всегда, ибо глупых людей всегда и везде полно.
Солидарен с Эйнштейном:
«Есть только две бесконечные вещи: Вселенная и глупость. Хотя насчет Вселенной я не вполне уверен.»
Что бы вёрска не лопалась от длинных слов можно использовать потенциальный перенос - тег <wbr /> или ­ или ​:
Оче<wbr />ньдл<wbr />инная<wbr />стр<wbr />ока
При отсутвии места может выглядеть вот так:
Оченьдл
иннаяст
рока
http://liketux.croe.net/wbr.png
Из преведённой выше таблицы видно, что целесообразно использовать ​ К тому же в отличие от тега сущность валидацию пройдёт.
Ну про производительность понятно. Поэтому хотелось что бы шифровались только указанные базыданных. Если углубить процесс шифрование в самые недры апи, то проблем со связность не будет, имхо, из опыта
1. Когда появится FULL JOIN? А то приходится жонглировать LEFT/RIGHT JOIN.
2. Когда нормально заработает GROUP BY id DESC? Поясню. GROUP BY группирует схожие записи, выбирая первую строчку из группы забивая на остальные. Из опыта скажу, что есть необходимость, сгрупировав, выводить последнюю из группы. Казалось бы для этого есть GROUP BY id DESC, но GROUP BY id DESC = GROUP BY id ORDER BY id DESC , что всё равно выводит первую строчку из группы и отсортировывает их...
Приходится использовать медленную констукцию:
SELECT id, type, data
FROM table
WHERE id IN (SELECT MAX(id) FROM table GROUP BY type)
3. Что-нибудь делается для ускорения JOIN?
4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
Если Продвижение такое плохое то почему они так интенсивно расширяются и количество клиентов у них давно за тысячу?
Кстати, человек, написавший статью о том как его увольняли, состоит на учете в псих диспансере (хотя по тексту это становится очевидным), так что это тоже не источник.
Не уподобляйтесь западной прессе освещающей Южно Осетинский конфликт :) Надо смотреть с разных сторон.
Солидарен с Эйнштейном:
«Есть только две бесконечные вещи: Вселенная и глупость. Хотя насчет Вселенной я не вполне уверен.»
Оче<wbr />ньдл<wbr />инная<wbr />стр<wbr />ока
При отсутвии места может выглядеть вот так:
Оченьдл
иннаяст
рока
http://liketux.croe.net/wbr.png
Из преведённой выше таблицы видно, что целесообразно использовать ​ К тому же в отличие от тега сущность валидацию пройдёт.
Имеется ввиду вытащить информацию из файлов БД
2. Когда нормально заработает GROUP BY id DESC? Поясню. GROUP BY группирует схожие записи, выбирая первую строчку из группы забивая на остальные. Из опыта скажу, что есть необходимость, сгрупировав, выводить последнюю из группы. Казалось бы для этого есть GROUP BY id DESC, но GROUP BY id DESC = GROUP BY id ORDER BY id DESC , что всё равно выводит первую строчку из группы и отсортировывает их...
Приходится использовать медленную констукцию:
SELECT id, type, data
FROM table
WHERE id IN (SELECT MAX(id) FROM table GROUP BY type)
3. Что-нибудь делается для ускорения JOIN?
4. Будет ли возможность шифровать БД? Если файлы MySQL сольют, то вытащить оттуда не составляет труда, имхо.
Думаю стоит подождать первых мнений о Mobile Ubuntu и Android.