- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени суток.
Интересует такой момент: если у меня таблица - каталог объектов или типа того, сотня тысяч записей с очень небольшим объемом информации (название, тип, адрес, ... итого десяток полей статической длины) и есть поле описания типа TEXT, в котором вряд ли будет больше пары предложений, но местами может быть и много букв.
Есть ли смысл делать не одну, а 2 таблицы - в первой индекс и все поля, в другой тот же индекс и текстовые описания?
Видел в DLE статистику выкинули в отдельную таблицу, но там чтобы запись статы не блокировала доступ к основной информации. У меня же получается что при части запросов текстовые описания не нужны. Уменьшение времени чтения из базы только за счет снижения размера просматриваемого файла на диске, но второй (лишний) запрос при отображении части страниц. Или это мелочь и нет смысла возиться?
Конечно, эксперимент с замером среднего времени никто не отменял но лучше спросить :)
Нет смысла если тянуть будет все сразу. Так вы только создадите 2 запроса. Для высоконагрузок используются http://habrahabr.ru/post/253017/
В вашем случае лимит на выборку и хватит.
Есть смысл конечно.
У Вас и поиск по основной таблице шустрее будет и поля будут фиксированной длины в ней, а не произвольной как сейчас.
SocFishing, не, пока обойдусь без шардинга и репликации, вот если реально будет высокая нагрузка - тогда уже подумаю. В связи с тем что почти все данные будут храниться в БД и большинство запросов - чтение, узким местом будет либо БД либо скорость диска, там можно будет сделать репликацию между парочкой VPS и коннектиться к рандомному mysql серверу из списка. Или анализировать нагрузку и переключать с одного на другой коэфициентом, теория вероятностей и все такое... Пока все не настолько запущено.
Вот это я хотел услышать. Значит, смысл есть
Не думаю, что будет заметный прирост на таком кол-ве записей. Попытка не пытка конечно или пытка.
Если выборка будет или критерии показа этих записей по времени скажем, то целесообразно оставлять эти индексы, а все остальное, включая текстовку описаний в отдельную таблицу. Тут все же следует плясать от выборки и как будет догружаться описание.
Я писал про то, что если вам на страницу надо выдать скажем все 100к записей с описанием, то само собой это не ускорит процесс, а затормозит его в виду 2х запросов =)
Если описание догружается после клика, то это порождение дополнительного запроса на веб-сервер и БД, что в купе с таким малочисленным описанием не очень будет. Быть может лучшим решением было бы не показывать сразу 1000 записей, а показывать порциями по лимиту с возможностью догрузки.
и есть поле описания типа TEXT, в котором вряд ли будет больше пары предложений, но местами может быть и много букв.
Поле типа Text оправдано только в записях типа статья, то есть когда текст это главное и текст может быть большим: максимум 65535 байтов, что на длину символа скажем в юникоде кириллицы - делим на 3.
Во всех остальных случаях для текстов применяют нормальные varchar поля с заведомо достаточным количеством букв.
Потому что текст это в сущности блоб https://dev.mysql.com/doc/refman/5.0/en/blob.html с той лишь разницей что драйвер "знает" как трансформировать байты поля типа текст. Следовательно такое блобное поле выпадает из рамок буферизации, требует особого с собой обращения что и влечет дополнительный расход ресурсов.
Короче говоря только некультурные люди втыкают тип text в кортеж о скажем товаре или пользователе, то есть когда в тексте фиксируются описания свойств, а не охрененная телега по истории КПСС.
В статье по ссылке выше оракл советует включать это поле в запрос только в крайних случаях. То есть достаточно его не запрашивать и запрос станет другим.
Поняли в принципе, правильно. Отображение будет списка, критериев выбора, скорее всего, будет много, текстовые описания будут подгружаться только в отдельных случаях. Возможно, для части списка скриптом будет собираться массив ID и отдельным запросом вытаскиваться описания записей с этими ID, либо после действия пользователя запрашиваться описание одного элемента списка