На самом деле критерий оч. простой. Большая часть тупых вопросов появляется от лени детской уверенности, что деточке все должны. Поэтому, если деточка путает Q&A сайт с учебником или с фриланс-биржей, задавая вопрос "вот код. почему он не работает" - такой вопрос заведомо должен удаляться. Если человекпрочел учебник, честно выполнил оттуда код, но не понимает, почему он работает - это хороший вопрос. Если человек учебника в глаза не видел, накалякал код от балды и хочет чтобы ему исправили - это плохой вопрос.
"На сём", мой юный друг, на "на сём". Общаться с такими как я полезно. Как минимум я заставил тебя переписать первоначальный ответ, который был вообще ни о чём. Плюс заставил перечитать вопрос целиком, а не только заголовок. Плюс научил думать перед тем, как строчить ответ, и не делать голословных бессмысленных заявлений. Кругом одна польза.
Ты не понял принцип, на котором была решена проблема. Если бы делалось так как ты говоришь, то размер индекса увеличился бы, а не уменьшился. Плюс, в любом случае, у парня не 200000000 записей, а 2000, и твои советы - исключительно попытка попонтоваться, без малейшей практической пользы. Но в целом второй вариант ответа чуть лучше чем первый, который был совсем ад.
Валентин: все верно. есть, правда, фишка с показом интересных вопросов на в сайдбаре на хабре , но чтобы вопрос там показался, надо чтобы его кто-нибудь отметил. Чтобы отметить его надо увидеть - замкнутый круг. А вообще да - хороших ответов на качественные вопросы тут ощутимо недостает
ответчиков нельзя в игнор ставить. их надо выпинывать каленым железом. Тут дело не в "нравится-не нравится". А в адовом стыде, который вызывают некоторые ответы.
Ну вот да, в этом беда с академическими вопросами. К примеру, те прайсы, которые обрабатываю я, содержат ссылки на картинки. И их одним SQL запросом уже никак. А так-то да, если логика умещается в SQL, то ON DUPLICATE подходящее решение.
возможно, в постгре это и так, но в мускуле составной - это тупо конкатенация двух ключей, и никакого "поиска по первому" не происходит. Если хотим сохранить уникальный ключ, то надо делать облегченный не в составе составного, а отдельным индексом, и форсить его использование. Учитывая, что в презентации явно написано, что размер ключа упал с 18 до 8, там тоже составной ключ не используется, а "поиск по первому" - твои фантазии.
Anton B: всегда старайся относиться к самому себе с долей иронии. Потому что когда человек впадает в грех пафоса, он перестает замечать, какую фню он несет. В частности, соотнеси предупреждение про ODKU, которое тебе дали выше, и свои сказки про 100М записей ;)
на выборку нужен адин запрос. в массив его записывать нинада. Все-таки, как честного человека, меня коробят фразы вида "но не столько, чтобы вытаскивать по одной строке из базы с целью экономии памяти", в то время как вытаскивать по одной строке - это единственно приемлемый вариант. Просто ты почему-то считаешь, что для выбора 2000 строк надо сделать 2000 запросов.
Про таких говорят "слышал звон, да не знает где он" :) Твоя проблема в том, что ты никогда не занимался такими вещами сам, а случайно услышал краем уха, когда пацаны базарили. Если ты делаешь облегченный индекс, то основной индекс надо снимать :) По облегченному мы находим 2-5 строк, для выбора между которыми не нужен индекс. То есть, alexclear (чувак, в отличие от тебя, действительно умный) сократил размер индекса, с чего и получил ускорение. В то время как ты размер индекса увеличил. Давно я так не смеялся :)
1 - диванная теория, 2 - норм, единственный полезный совет во всем ответе. 3 можно, но не принципиально. 4 - диванный ад, кромешный :) Все что ты сделал - это УВЕЛИЧИЛ размер индекса, не прибавив ничего к скорости :)
Разуй глаза. Когда это нормальный вопрос по программированию заходил в топ? Там каждый день новый вопрос "Куда пойти учиться", который и собирает кучу подписок от такой же ламерни.
