Вообще, для меня это очень интересная тема в применении к саморегуляции в системе электронной демократии. Все более явственно возникает идея, что нужна социальная сеть, в которой, в том числе, будут такие «графы компетенций», формируемые другими участниками системы.
Возможно, что это справедливо для MySQL. В postgresql я это тестировал и обнаружил что для LIMIT практически нет зависимости от величины смещения. По крайней мере если сортировка идет по PK.
Если вы по третий метод, то это надо тестировать. Я не уверен что именно быстрее. Возможно вы и правы. Но, думаю, разница по времени будет не существенная.
Если заранее известно количество элементов, тогда выборка по случайному offset будет намного эффективнее. Я проверял это на postgresql и mysql — разница, насколько я помню, в 5-10 раз в пользу выборки по смещению.
Хочется отметить, что при использовании rand() в SQL выражении идут лесом любые индексы и оптимизации по ним. Так что категорически не советую его использовать в выражениях WHERE или ORDER.
Ну, я всю свою сознательную жизнь использую биндинг параметров. Поэтому для меня кажется карйне странным что вместо того, что-бы сделать биндинг в библиотеке, используют различные костыли типа экранирования опасного контента в строках.
Шаблонизатор — Template
Менеджер процессов для FastCGI — FCGI::ProcManager
Работа с мемкэшем — Cache::Memcached (Cache::Memcached::Fast я пробовал, но он падал при нагрузке)
Вот именно что «Нужно иметь доверие». Основной принцип нашего проекта — никому не надо доверять. В системе не должно быть особых людей. И как следствие — особых серверов. Такое возможно только в распределенной и самоуправляемой сообществом системе.
Ну, опрос мнения — это, все-таки, не голосование. Хотя, как второстепенная задача, может выполняться той-же системой.
Вообще, не полностью согласен с тем, что иногда может не быть заранее составленного списка.
В любом голосовании должны быть голосующие, которые к нему допускаются. Т.е. в любом случае есть некий критерий допуска к голосованию. И тут у нас дилема — либо выбирать кого-то, кто будет решать, допущен данный голосующий к голосованию или нет (то, что есть сейчас — чревато коррупцией и подделками), либо доверить эту функцию самому сообществу голосующих в данном голосовании. Мы придерживаемся второго варианта. Тут, конечно, нет фиксированного списка голосующих, но есть некоторая динамическая система, с помощью которой его, в принципе, можно составить на какой-то момент времени.
Если выбирается директор предприятия, то там все намного проще. Если это акционерное общество, есть база акционеров. И голосования будут проходить через нее.
Если нет, есть список сотрудников предприятия в базе отдела кадров.
В данном случае все, как раз, намного проще чем при более глобальном голосовании.
Ну, паспорта вроде как можно проверить чуть-ли не автоматически на каком-то гос. сайте.
Но в общем, вы правы. Если смотреть на реальность, да еще и на закон о персональных данных — это будет проблемой. Но в идеальном случае, это может быть решением.
У нас в проекте эта проблема решается через систему обратной связи, когда любой голосующий может проверить реальность любого другого голосующего. Предоставление персональных данных один-на-один вроде как не регулируется законом.
В булевой математике существует малоизвестная функция XOR, которую можно применять для побитового шифрования данных заданным ключом, повторяя его, если он короче шифруемых данных!
Спасибо, посмеялся. :)
Вы вообще понимаете в чем особенности шифрования с открытым ключем? И в чем удобство именно такого метода шифрования?
Теоретически, при указании кроме ФИО еще, например, и номера паспорта (не говоря уж о СНИЛС или других идентификаторах), возможно сделать даже автоматическую проверку голосовавших. Естественно, что такая система не исключает что за человека просто проголосует мошенник. Но в открытых голосованиях такое выявляется достаточно просто. В отличии от закрытых.
Вброс. Может внезапно оказаться, что у нас в стране есть дополнительные 50 миллионов избирателей, единым порывом голосовавших за свою любимую партию/кандидата. Даже в этом случае результат подсчётов сможет отклониться от реальности уже не так значительно, так как вброс — не подмена, и его возможности принципиально ограничены данными статистики и здравым смыслом.
К сожалению, даже при такой системе никакой защиты от вбросов. А это как раз одна из главных проблем голосований. Ее можно избежать в полностью открытых голосованиях. Но, де-факто, все голосования невозможно сделать открытыми. Т.к. в голосованиях, от которых зависит распределение ресурсов, их открытость напрямую будет способствовать «коррупционноому» их распределению.
А при тайном голосовании обеспечить отсутствие вбросов можно лишь предусмотрев проверки голосовавших пост-фактум. И исключая из процесса голосования тех, кто однажды участвовал в таких махинациях. Такое возможно лишь при формировании сети доверия избирателей. И организации структуры обратной связи в такой сети.
Так что задача организации нормальных голосований не такая очевидная, как может показаться на первый взгляд.
Ну, хотя-бы тем, что методика голосования непонятна. У голосующего есть два кода, как я понял. Но что они означают и взаимосвязь между ними не смог понять. Кроме того, не вижу в какой именно момент производиться выбор нужного варианта. И в чем он заключается.
Что-то я не совсем понимаю как это работает. Выглядит сложнова-то. Вот вы в этой системе разбираетесь, и ответте, возможно-ли по какой-то из опубликованных таблиц что-бы любой из голосующих мог проверить правильность учета своего голоса и при этом мог подсчитать общий результат?
Хочется отметить, что при использовании rand() в SQL выражении идут лесом любые индексы и оптимизации по ним. Так что категорически не советую его использовать в выражениях WHERE или ORDER.
Менеджер процессов для FastCGI — FCGI::ProcManager
Работа с мемкэшем — Cache::Memcached (Cache::Memcached::Fast я пробовал, но он падал при нагрузке)
Вообще, не полностью согласен с тем, что иногда может не быть заранее составленного списка.
В любом голосовании должны быть голосующие, которые к нему допускаются. Т.е. в любом случае есть некий критерий допуска к голосованию. И тут у нас дилема — либо выбирать кого-то, кто будет решать, допущен данный голосующий к голосованию или нет (то, что есть сейчас — чревато коррупцией и подделками), либо доверить эту функцию самому сообществу голосующих в данном голосовании. Мы придерживаемся второго варианта. Тут, конечно, нет фиксированного списка голосующих, но есть некоторая динамическая система, с помощью которой его, в принципе, можно составить на какой-то момент времени.
Если нет, есть список сотрудников предприятия в базе отдела кадров.
В данном случае все, как раз, намного проще чем при более глобальном голосовании.
Но в общем, вы правы. Если смотреть на реальность, да еще и на закон о персональных данных — это будет проблемой. Но в идеальном случае, это может быть решением.
У нас в проекте эта проблема решается через систему обратной связи, когда любой голосующий может проверить реальность любого другого голосующего. Предоставление персональных данных один-на-один вроде как не регулируется законом.
Спасибо, посмеялся. :)
Вы вообще понимаете в чем особенности шифрования с открытым ключем? И в чем удобство именно такого метода шифрования?
К сожалению, даже при такой системе никакой защиты от вбросов. А это как раз одна из главных проблем голосований. Ее можно избежать в полностью открытых голосованиях. Но, де-факто, все голосования невозможно сделать открытыми. Т.к. в голосованиях, от которых зависит распределение ресурсов, их открытость напрямую будет способствовать «коррупционноому» их распределению.
А при тайном голосовании обеспечить отсутствие вбросов можно лишь предусмотрев проверки голосовавших пост-фактум. И исключая из процесса голосования тех, кто однажды участвовал в таких махинациях. Такое возможно лишь при формировании сети доверия избирателей. И организации структуры обратной связи в такой сети.
Так что задача организации нормальных голосований не такая очевидная, как может показаться на первый взгляд.