1) это где нельзя, в MySQL?
2) операцией сложения добавил к каждой неуникальной строке 2 случайных цифры. или что вы имеете ввиду под "прибил" ?---------- Добавлено в 18:31 ---------- Предыдущее сообщение было в 18:23 ----------но вообще-то да, неправильно написал, он прибавит к каждой неуникальной :-(, а надо только к одной
ваш update, кстати, тем же болеет ;-)
вот так будет правильнее
добавит два случайных числа к id
1. Получить временнУю зону getTimezoneOffset()
2. Прибавить ее к текущему времени - получим UTC
3. Вашингтон, если мне не изменяет память, живет позади Лондона на 5 часов, значит добавляем -5 (ну или отнимаем 5), получаем время в Вашингтоне.
Не забываем только переводить все в миллисекунды - getTimezoneOffset возвращает в минутах (т.е. умножить на 60000 надо), 5 часов тоже перевести в миллисекунды нужно (умножить на 3600000).
Т.е. вместо строчки old.setTime(....... пишете
Он еще null может быть, если мне память не изменяет
Вы правильно понимаете что это незаконно.
Есть два пути - задействовать закон или использовать прокси. Понятно, что второй путь существенно проще.
Если идти по первому пути, то совершенно неважно что прописано в договоре - если договор нарушает закон, то договор признается ничтожным. Понятно что провайдер может прописывать пункты о "технической невозможности" или другой подобный бред - а значит привлечение экспертов и прочий геморой. В идеальном мире дело конечно выигрывается, на практике... На практике зачастую достаточно грамотно составленное ( обязательно с помощью юриста) письмо к провайдеру - там тоже не дураки сидят.
С точки зрения провайдерского бизнеса - дешевле отказаться от проблемного клиента и пусть он мозги трахает конкурентам - тут pupseg прав.---------- Добавлено в 10:39 ---------- Предыдущее сообщение было в 10:32 ----------
это вы напрасно, раньше эти пользователи удовлетворяли свои, гм, потребности перед монитором, а теперь на улицу вышли.
Да и вообще, не суди, да не судим будешь
конечно мы можем заставить использовать индекс. в этом случае мы сначала будем ходить по индексу, а потом пойдем за данными в таблицу, т.е. получим 2 IO операции вместо одной, но нам же не это нужно, правда?
суть в том, что в данном случае нет никаких преимуществ в использовании индекса по сравнению с table scan, а недостатки известны - дополнительное место под индекс, перестройка (а значит локи) индекса при вставке-удалении-апдейте.
оптимизатор может выбрать использовать индекс в трех случаях
а) индекс кластерный - т.е. данные хранятся физически вместе с индексом
б) таблица достаточно широкая - может получиться что шагать по индексу дешевле (в терминах IO) чем шагать по таблице
в) в селекте выбирается только те колонки, из которых состоит индекс
1) стала ли использоваться вся память?
2) уменьшилась ли нагрузка на диски?
вроде бы эти проблемы озвучивались в первом посте
поток висит и ждет пока удаленный компьютер что-то ему скажет.
два варианта
а) использовать неблокирующие сокеты
б) создать отдельный поток для слушания удаленного компьютера
нельзя ли поподробнее отсюда?
при чем здесь денормализация?
на вопрос "зачем" уже вроде ответили - чтобы извращения не писать в виде "substring(substring("
действительно, иногда лучше жувать.
я вот проверил, при "!=" составной индекс не используется. такой же запрос, но с "=" - используется.
если немножко подумать о том, как устроены индексы и как по ним поиск идет, то можно догадаться почему именно так, а не иначе.---------- Добавлено в 23:42 ---------- Предыдущее сообщение было в 23:40 ----------
да не, тут не про IN/OR - это синтетический сахар, тут про "!=" vs "="
