Тут надо тесты проводить по хорошему. Я думаю, что запросы будут одинаковыми по скорости, если оптимизатор mysql просечет фишку и сконвертирует дату 2009-05-01 в число, а потом будет делать выборку на основе сравнения чисел.
Потому что главное подсадить (а через тебя и возможно твоих знакомых). А со старыми клиентами можно и не церемонится — им часто очень трудно сползти с оператора — куче знакомых раздавать новый номер, внутрисетевые скидки пропадут опять же. Но главное — потеря номера.
Если введут законы/правила, позволяющие абненту менять оператора без смены ОПСОС-а — ситуация изменится радикально!
>> Как вы предлагаете например вставить в таблицу 10000 записей?
Рекомендую так (примерно, я не знаю php):
INSERT INTO table (col1,col2) VALUES
for ($i=1; $i<=10000; $i++)
{
(...тут значения столбцов...)
}[, ]
Так не получится в одном случае — если вы вставляете достаточно большие значения и суммарный запрос превысит лимит размера запроса, установленный на сервере (по умолчанию 1Mb, если мне память не изменяет).
Делать 10000 инсертов в такой ситуации — это очень неоптимально.
>> А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
У mysql полно функций, работающих с датами, практически всегда можно найти нужную под задачу.
>> И на счёт MD5 не согласен. Лучше возложить это на php.
Вы хоть какие то доводы привели бы. Почему лучше? Потому что лично вам так нравится больше? Или потому что вы просто возможности mysql знаете гораздо меньше, чем возможности php?
Бррр… я окончательно запутался в том, кто про что пишет, потому в предыдущем комментарии написал вообще нечто, никак не связанное с вашими словами выше. Произвожу корректировку :)
Вы написали следующее (на что я вам ответил про вариант с int, что не к селу ни к городу)
>> думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
Ответ — неверно. TIMESTAMP — это тоже временной тип данных, поэтому все функции применимые к DATETIME применимы и к TIMESTAMP. Разница лишь в методе хранения этих типов — DATETIME хранится в виде числа! YYYYMMDDHHMMSS, а TIMESTAMP в виде количества секунд с Epoch. Не считая еще описанной в топике разницы с TZ, того, что timestamp не может быть null, и фич с автоапдейтом, с точки зрения программиста они одинаковы. Но внутренее хранение накладывает еще и свои различия — DT больше TS в два раза, зато позволяет записывать даты произвольные, а не с 70 по 38 год.
И всё таки про индексы тоже скажу. Раз вы про них упомянули, значит речь идет об использовании этих функций в WHERE (или join, что тоже самое). Скажите, почему вы решили, что например
.... WHERE YEARWEEK(FROM_UNIXTIMESTAMP(`unixtime`)) = 200922 ...
Долго пытался понять, что не понравилось Николаю до степени уг, заметил такое —
вначале — timeoutID = window.setTimeout(func|code, delay)
в конце — var timeout_id = setTimeout(...)
Можно долго спорить об наилучшем стиле именования переменных, но одно я думаю бесспорно — хоть какая то система быть обязана. хоть какая то, а не то так, то так.
Потому что «публикатор» указывает в топике истинного автора. Тем кому топик понравится — пойдут и плюсанут, всё просто. Насчет лени — телодвижений столько же, но народ на хабре, я считаю, всё-таки адекватный и за топики благодарят кармой автора гораздо активнее, чем за комментарии, тем более когда видят, что помочь надо адекватному автору, от которого можно ожидать и других хороших топиков. Опять же практика — jeje вылез из -40 за несколько дней.
Что такое «реактивные минусы кармы» я не понял. Ответственности за минусы, полагаю, на хабре не будет никогда, анонимность голоса — базовый элемент концепции.
Доступный метод реабилитации и так существует — выше jeje его описал достаточно понятно. Метод работает, проверено на практике. Конечно метод не идеален, но он доступен без каких либо изменений системы. Чем не устраивает?
Кстати мне пришла в голову отличная идея!!!
Нужна просто возможность перенаправления потока плюсов и минусов. Т.е. допустим у A -10 в карме — писать не может, у B — много (не важно сколько). A просит B опубликовать статью, что B и делает, но в настройках топика указывает истинного автора/хабрапользователя — куда все оценки за топик и уходят. Вроде просто и элегантно :)
Ну нам то может и ничего, но главное, что они не достанутся автору. Переопубликовать же статью по новой он уже не сможет. Для кого то это важно, для кого то нет.
По мне лучше всего, чтобы люди могли публиковать статьи не с больше нуля, а где то с -5 в карме, чтобы исключить влияние случайного комментария. А то человек напишет где-нибудь что-то спорное в каментах, раз-два минуса и всё, писать уже не может, надо просить кого то — неправильно это.
>> Далее берется человек из рейтинга
Ага, а некоторые и сами предлагают. Вот чертяка — спалил схему :))
На самом деле изначально мне такая схема не очень нравится по одной простой причине — бонусы (если они будут) получает не только автор статьи, но и «публикатор». Так пытались зарабатывать инвайты по началу, когда не было песочницы. Лучше бы конечно чтобы был какой то встроенный механизм. Но до тех пор пока его нет и не предвидится — опубликовать через кого то свою статью — единственный возможный способ. И если автор адекватен, у него не -200 в карме и статья хорошая — то он с легкостью найдет того, кто ему поможет. Кстати не только в top-20, я бы сказал в top-100. Так что желающие — пишите.
Если введут законы/правила, позволяющие абненту менять оператора без смены ОПСОС-а — ситуация изменится радикально!
Рекомендую так (примерно, я не знаю php):
INSERT INTO table (col1,col2) VALUESfor ($i=1; $i<=10000; $i++)
{
(...тут значения столбцов...)
}[, ]
Так не получится в одном случае — если вы вставляете достаточно большие значения и суммарный запрос превысит лимит размера запроса, установленный на сервере (по умолчанию 1Mb, если мне память не изменяет).
Делать 10000 инсертов в такой ситуации — это очень неоптимально.
>> А если мне нужно чтобы в поле reg_time был не текущий timestamp, а + один день?
У mysql полно функций, работающих с датами, практически всегда можно найти нужную под задачу.
>> И на счёт MD5 не согласен. Лучше возложить это на php.
Вы хоть какие то доводы привели бы. Почему лучше? Потому что лично вам так нравится больше? Или потому что вы просто возможности mysql знаете гораздо меньше, чем возможности php?
Вы написали следующее (на что я вам ответил про вариант с int, что не к селу ни к городу)
>> думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
Ответ — неверно. TIMESTAMP — это тоже временной тип данных, поэтому все функции применимые к DATETIME применимы и к TIMESTAMP. Разница лишь в методе хранения этих типов — DATETIME хранится в виде числа! YYYYMMDDHHMMSS, а TIMESTAMP в виде количества секунд с Epoch. Не считая еще описанной в топике разницы с TZ, того, что timestamp не может быть null, и фич с автоапдейтом, с точки зрения программиста они одинаковы. Но внутренее хранение накладывает еще и свои различия — DT больше TS в два раза, зато позволяет записывать даты произвольные, а не с 70 по 38 год.
И всё таки про индексы тоже скажу. Раз вы про них упомянули, значит речь идет об использовании этих функций в WHERE (или join, что тоже самое). Скажите, почему вы решили, что например
.... WHERE YEARWEEK(FROM_UNIXTIMESTAMP(`unixtime`)) = 200922 ...не будет использовать индексы, а
.... WHERE YEARWEEK(`datetime`) = 200922 ...— будет? Индекс не будет работать в обоих случаях
Ну а раз уж зашли — может расскажете почему вам кажется дикостью данный топик, просветите окружающих?
вначале — timeoutID = window.setTimeout(func|code, delay)
в конце — var timeout_id = setTimeout(...)
Можно долго спорить об наилучшем стиле именования переменных, но одно я думаю бесспорно — хоть какая то система быть обязана. хоть какая то, а не то так, то так.
Что такое «реактивные минусы кармы» я не понял. Ответственности за минусы, полагаю, на хабре не будет никогда, анонимность голоса — базовый элемент концепции.
Скоро будут топики-переводы твитов…
По моему такой объем материала надо на микрохабре постить.
Процедуральное? А чего тогда не объектарно-ориентировочное?
Нужна просто возможность перенаправления потока плюсов и минусов. Т.е. допустим у A -10 в карме — писать не может, у B — много (не важно сколько). A просит B опубликовать статью, что B и делает, но в настройках топика указывает истинного автора/хабрапользователя — куда все оценки за топик и уходят. Вроде просто и элегантно :)
По мне лучше всего, чтобы люди могли публиковать статьи не с больше нуля, а где то с -5 в карме, чтобы исключить влияние случайного комментария. А то человек напишет где-нибудь что-то спорное в каментах, раз-два минуса и всё, писать уже не может, надо просить кого то — неправильно это.
Ага, а некоторые и сами предлагают. Вот чертяка — спалил схему :))
На самом деле изначально мне такая схема не очень нравится по одной простой причине — бонусы (если они будут) получает не только автор статьи, но и «публикатор». Так пытались зарабатывать инвайты по началу, когда не было песочницы. Лучше бы конечно чтобы был какой то встроенный механизм. Но до тех пор пока его нет и не предвидится — опубликовать через кого то свою статью — единственный возможный способ. И если автор адекватен, у него не -200 в карме и статья хорошая — то он с легкостью найдет того, кто ему поможет. Кстати не только в top-20, я бы сказал в top-100. Так что желающие — пишите.