Код почему то не видит параметры GET запросы. Перехожу по /account/register?refid=1 и в итоге значение 1 он не видит, а записывает значение 0. В чем проблема?
MrSullex пишет:
RewriteRule ^(.*)$ index.php?action=$1 [L,QSA]
короче ваш запрос преобразовывается к виду: index.php?action=/account/register?refid=1
Если запрос будет такого рода, то параметры должны в $_GET появится:
/account/register&refid=1
Да примерно так, спасибо. Жаль кнопку спасибо нажать не могу, говорит сообщений мало. Сколько же их надо набрать и смысл в этом наборе...
Мне не совсем понятно зачем тут (($p = getParent($userId)) > 0)
больше нуля? Оно может быть равно или меньше?
и тут
$k = [0.2,0.05, 0.0125 ...]; // коэффициент
если тут он руками задан руками...
Я исходил из того, что функция getParent селектит из базы данных id пользователя который пригласил этого пользователя. Результат записываем в $p, однако если учесть, что пользователя возможно некто не пригласил, тогда функция getParent вернет 0, и цикл прервется т.к. дойдет до логического предела цепочки.
Ну в первом примере коэффициент задан руками для каждого уровня, однако вместо этого можно сделать, как я описал в предыдущем посте:
В принципе ваша идея мне понятна, но мне кажется, поправьте если ошибаюсь, тут с коэфицентами надо поработать.. У вас они задаются железно.. А надо наверное их создавать под каждого юзера в зависимости от вложенности.. То есть есть уровень вложенности и на него надо поделить сумму отдачи процента пользователя выстроив в какой-то прогрессии.
Не, гоню? Или как?
Вообще то массив коэффициентов для того и нужен чтобы в нем определить бонусы для всех уровней и количество этих уровней.
$i - определяет уровень вложенности,
$k[$i] - коэффициент для данного уровня,
count($k) - количество уровней
Рачей пишет:
Теперь бы еще придумать откуда брать бонусы на партнеров вверх.. Закладывать в цену рекламодателя? тут надо крепко будет подумать.
тут всё просто на самом деле, определить одну цифру: со сколькими % готов расстаться - допустим это Х
а далее делаешь так:
1) Х/2 отдаешь первому уровню
2) каждый последующий получает в 2 раза меньше т.е. Х/4, Х/8, X/16 и т.д.
3) больше 10 уровней делать думаю смысла нет (т.к. доля % будет слишком ничтожна мала), другой вопрос, что врятли когда нибудь их столько будет - поэтому вообще можно не ограничивать уровни, а разделять до последнего пока сумма допустим не будет меньше копейки. В итоге до 6-8 уровня максимум что еще и дойдет. (Добавление)
Если решишь реализовывать по этой схеме, тогда сумма издержек на бонусы будет стримится к Х, но никогда не будет больше... собственно поэтому этот Х и надо определить ;)
Думаю на сайте сделать партнерку, сижу думаю как их считать.. До какого уровня? Как обычно высчитываются, у кого опыт есть? Там еще до второго третьего уровня не сложно, а если их будет от первого до последнего 30 уровней... Как быть? Составлять дерево или при совершении действия крайнего пользователя пересчитывать все до первого уровня? Поделитесь опытом.
Конкретно с партнеркой дело не имел, но с многоуровневыми зависимыми данными возился..
тут всё просто отмечаешь, кто чей реферал и при возникновении события за которым должно последовать вознаграждение до требуемого "колена" циклично начисляешь "бонусы" всё просто..
И так сделал таймлаин и замерил скорость на разных этапах..
До оптимизации 1065 строк обновлял в пределах 12-13 секунд
С транзакцией 17-18к строк глотает за 4 секунды, всё круто спасибо... с учетом загрузки выборки и манипуляций за 8 секунд отработал - всё супер
PS: начал PDO вылетать с неизвестной ошибкой... заглянул в класс соединения и о боже заметил, что там для каждого запроса создается новый экземпляр PDO.. теперь всё ок
Всосать 30тыс записей, сверить их с имеющимися данными в таблице, отчитаться на приложение о найденных аномалиях, смержить с таблицей, прогнать весь массив этих данных через реферальную программу, пересчитать ещё штуки 3 таблицы аггрегации - запросто. Всё перечисленное - 5 секунд реального времени.
т.е. сделать селект устаревших данных прогнать аномалии и внести изменения через транзакцию как то так?
3,5 Мб. текста через preg_match_all довольно быстро делятся на 20 000 строк (в пределах секунды) для обновления параметров в бд, все данные это цифры. Данные должны обновляться раз в минуту. Проблема в том, что обновление параметров идет крайне медленно... за минуту еле успевает обновится половина.
Не силен в настройке mysql сервера, может стоит что то там поковырять и выделить больше ресурсов (ЦП и память далеки от полной нагрузки)?
По хорошему то на редис или мемкеш перебросить все это и тогда бы проблема отвалилась, но пока так, как есть.
Apache-2.4+Nginx-1
PHP-5.6
MySQL-5.6 (Добавление)
если mysql в любом случае не сможет обработать хотя бы 1000, а лучше 2000 update в секунду на 5 чисел int, тогда буду менять концепцию... или все таки может?
Проверки это хорошо, конечно, но у меня просто меняется значение с каждым новым POST, хоть убейте.
$arr = [1,25,12,48, вот сюда добавляет, а потом только меняет];
if(isset($_POST['id']) || die('Значение не передано')) {
$arr[] = $_POST['id'];
}
ахах) ну конечно, же... потому, что каждый новый раз, при отправке POST данных у вас запускается новый скрипт, который не может иметь прямого доступа к данным из уже отработавшего скрипта.
Для того, чтобы собирать все значения, Вам нужно записывать их в файл или базу данных и потом оттуда доставать
if(isset($_POST['id'])||die('Значение не передано')){
$arr[]=$_POST['id'];
}
В первом примере у вас всё было верно, так и надо добавлять. Только проверку лучше ставить на существование, потому что если допустим id будет равно 0, тогда условие не пройдет.
Так же рекомендую проверять post-данные, если это число int то как то так:
Подскажите как удалить пустые ячейки. При этом сохранив структуру таблицы.
т.е. у тебя есть HTML-таблица, из которой ты хочешь удалить ПУСТЫЕ ячейки. Каким именно образом?
Задача не ясна, куда должны исчезнуть пустые ячейки? что должно быть на их месте?
И да, очень лютая абракадабра в реализации... (Добавление)
Запустил я это счастье и ужаснулся результату) У вас там явно лишний цикл, далее какая то охинея с выводом <tr> почему то он выводится в разных циклах, поэтому таблица и едет к чертям. Причем в шапке <tr> напрочь отсутствует.
Так вроде лучше:
как-то всё слишком запутанно, это всё-таки раздел для новичков, никак попроще нельзя?
Для каждой задачи, есть много вариантов решения, я тебе подсказал, один из наиболее логичных и правильных(по моему мнению) из поставленной задачи, если запустишь код, поковыряешь, разберешься с ним, затем прочитаешь мануал про то, чего не понимаешь, думаю всё будет легко и просто. (Добавление)
Сейчас добавлю комментарии в предыдущий пост, чтобы тебе было проще и понятней