- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
ЧПУ - это всего навсего роутинг, который перенаправляет на код, который будет делать запросы в БД, например. Как вы его оформляете - никакого значения не имеет в плане скорости.
Тем не менее, если в ЧПУ вставить идентификатор элемента, то это уже готовый ключ для выборки из БД. Об этом речь.
это сразу привело к тому что поехал запрос в БД?
Сразу или не сразу, но в конечном итоге это всё равно приведёт к запросу к БД на предмет наличия соответствующего строкового поля.
нет. я к тому что например ID можно генерить самому. уник. допустим 8-10 символов. в то время как slug новости может быть длинным. не все новости
будут и такие
Старовойт: Михайловский ГОК второй раз за утро атаковал украинский дрон
Песков: американские танки горят, то же самое будет и с самолетами США
Рособрнадзор: выпускники уже в июне смогут пересдавать ЕГЭ по предмету на выбор
А разве индексы в БД это не массив хэшей?
Если мы говорим о b-tree, то скорее двусвязный список, нодами которого являются массивы.
Тут избыточность мне кажется не причем...
Для хеша в b-tree нужны 2 момента - уникальность и постоянный размер. Целое число удовлятворяет обоим критериям:
- оно так уникально - его не надо ещё раз уникализировать
- размер (например INT) всегда 4 байта
Если мы говорим о b-tree, то скорее двусвязный список, нодами которого являются массивы.
Для хеша в b-tree нужны 2 момента - уникальность и постоянный размер. Целое число удовлятворяет обоим критериям:
- оно так уникально - его не надо ещё раз уникализировать
- размер (например INT) всегда 4 байта
Чем логичнее? =) То что знаков больше? Так по вашему ID 10000000 будет искаться дольше чем строка address
Ключи в БД не выглядят как их значения, то что вы видите цифру 1 ключ это не цифра 1 =))
у вас каша в голове, несмотря на то, что вы знаете, что такое b-tree, вы не знаете что такое целые числа, они не хранятся в виде строк!
у вас каша в голове, несмотря на то, что вы знаете, что такое b-tree, вы не знаете что такое целые числа, они не хранятся в виде строк!
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
Вы можете думать что угодно, я же вам предлагаю проверить.
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
В плане Постгрес это могут быть и b-tree, HASH, GIST, но да - это все строковые данные, которые проигрывают по скорости b-tree с числами, конечно, зависит от вида поиска, например это точное совпадение или диапазон или полнотекст.
так что по факту да - для простого запроса будет, например быстрее получить статью из базы по полю айди чем по текстовому полю(индексу)
Только вот покажите мне тот идеальный мир, где можно обойтись такими простыми вещами?
Я вам задам другой вопрос, кто вам сказал что строки в индексе хранятся в виде строк? =))
Вы можете думать что угодно, я же вам предлагаю проверить.
так что по факту да - для простого запроса будет, например быстрее получить статью из базы по полю айди чем по текстовому полю(индексу)
Там если и будет разница, то фактически нивелироваться железом, вот табличка на 1.5kk записей
И в ней 3 индекса, 1 праймари и 2 составных (один чисто числовой, второй имеет строку) и собственно вот запросы
По праймари кею
По первому составному из 2х чисел
И из 2х чисел со строкой
В общем тут на уровне погрешности разница между ними и это вполне логично
вы просто занимаетесь словоблудием, магии нет, строки занимают больше места, чем числа, сравнение строк накладнее по ресурсам, чем сравнение целых чисел, ваш коллега Sly32 уже признал мою правоту
Вы можете дальше жить в своем неведении и считать что ID в строке даст вам какой то значительный буст =))