mysql запрос

[Gambit_J]

кто еще не пользовался этими смайлами, добавляйте! :facepalm::facepalm::facepalm:

зачем использовать ранд? Да и еще от нуля?

Объясняю:

1. Если попадется 0, то значит 100% попадание что запрос не выполнится. тада уже лучше делать mt_rand(1, 99). да и лучше использовать mt_rand() - работает в 4 раза быстрее (хотя бы поэтому).

2. Зачем вообще использовать ранд? Если хотите сделать отрыв, сделайте +10 или +50 как можно больше, чтоб наверняка.

Вывод: как лучший вариант реализовать item_delay, но на сколько мне ясно, наврятли Вы это сделаете и навряли вообще обладаете знаниями в яве, а значит просите у кого-то за деньги или за спасибку. Как вариант № 2 делаете так как я сказал, при неудачном запросе выполняется другой (100% ) запрос с инфой о попытке сдонатить в вашу табличку созданную. Там уже если будут жаловать, хотябы восстановить сможете.

Иные варианты (возможно бредовые) :

- Сделать цикл на выполнение при неудачке
- сделать +10 или 50 (чтоб наверника) в обжект_ид, но в случае если сборка заполняет пропущенные ид, что наврятли (уточняйте у ява кодеров). Предположим даже, если и не заполняет обж_ид пропущенные, то при высоком/активном онлайне это может грозить быстрым исчерпанием ИД (если конечно верить слухам, что ИД все таки скончаемый ).

Как работает чтение ИД на сервере Вы интересовались - так же как и на php вы делаете в запросе, считывается в базе максимальный ИД. ИМХО, других вариантов не вижу.

Добавлено через 6 минут

диапазон от 500000000 до 599999999, его должно хватить. Длинна записи 9 символов- нормально, 1млрд записей думаю хватит на долго. Как думаете?

такое впечатление как будто Вы функцию рандом (случайный выбор от 0, 999.. ) принимаете как какой-то резерв для чего то.

Добавлено через 13 минут

Ro_0TT, Вы пишете про item_delay, но тоже никаких аргументов, чем это лучше обработчика.

Это самый лучший вариант, даже не обсуждаеться. Объясняю как он работает.

Есть 2 таблицы:
- items (для хранения итемов)
- items_delay (для хранения временных итемов)

Т. е. скрипт на php делает запрос в items_delay. Т. е. в эту таблицу запрос на инсерт делает только 1 поток - это внешний (в вашем случае php скрипт). Мы делаем запрос именно туда. Далее уже сервер через каждые 5 минут (может больше/меньше, хз ) делает проверку, есть ли в этой таблицы еще не розданные итемы. Если они есть, то он раздает их сам, т. е. сам обрабатывает. Тут сбоя просто не может быть. Как он проверяет раздавался ли итем - колонка status отвечает, при запросе скрипт делает Insert... status=0, а когда сервер уже обработал он делает UPDATE status=1. Думая ясно.

[Jocker]

Ок, давайте по- порядку. Да, Java я врятли буду ковырять. Если бы я шарил, то обратился бы в отдельный раздел этого форума.

1. Если попадется 0, то значит 100% попадание что запрос не выполнится

согласен. Если рандом выдаст "0", то такой ID уже будет использован. Быстродействие в этом случае не слишком важна т.к. я не ожидаю больше ~20ти донов в сутки. При неудачной генерации выполняется цикл на повтор- это думаю неотъемлемая часть такого скрипта.

от 500000000 до 599999999

вообще то да. Если по этому принципу делать, то надо создавать сразу итем с id 600000000, чтоб сервер создавал значения >600000000, а от 500000000 до 599999999 это резерв под создание итемов php скриптом.
С таблицей item_delay понятно, но это нужно делать Java скрипт на перенос нерозданных итемов в таблицу items каждые 5 минут, но как выше я уже говорил, Java я не жевал ещё, так что как не прискорбно, реализовывать надо на php в моём случае. Остается один вопрос: чем опасно выполнение одного сценария несколькими обработчиками? В нашем случае добавление итемов в одну таблицу Java скриптом со стороны сервера и php со стороны сайта (если я правильно понял эту тему).

[Gambit_J]

Во первых, выкиньте из головы вообще идею с rand().
Во вторых:

Остается один вопрос: чем опасно выполнение одного сценария несколькими обработчиками? В нашем случае добавление итемов в одну таблицу Java скриптом со стороны сервера и php со стороны сайта (если я правильно понял эту тему).

Вы еще не поняли? 2 потока не общаются между собой, 1 поток сам делает все по порядку, 2й так же, а когда они вместе то может произойти казус, так как они не общаются между собой. Грубый пример:
- 1й: погоди 2й поток, я первый сделал запрос
- 2й: ок я след. сделаю

Добавлено через 33 секунды
P.S. пасибку и +

[Jocker]

Defuse, без знания Java будет слишком сложно реализовать скрипт периодического зачисления итемов из временной item_delay.sql в itеms.sql средствами сервера?

[Gambit_J]

Defuse, без знания Java будет слишком сложно реализовать скрипт периодического зачисления итемов из временной item_delay.sql в itеms.sql средствами сервера?

без понятия, я с явой не работаю.

[x3k]

на сколько можно судить, ГС же не запоминает какие ID он уже записал... То есть принцип тоже $object_id ++n. Максимальное число ID думаю ограничивается только длинной записи в БД. То есть много.

Добавлено через 3 минуты
короче я сделал $object_id + rand(0,999999999), то есть тут врятли совпадения произойдут в течении нескольких лет точно...

Говнокод детектед:dr:

PHP код:

<?php 

function gen_object_id(){

    

    $object_id = '';



    $num = array(1, 2, 3, 4, 5, 6, 7, 8, 9, 0);



    for ($i=0, $i<=999999999, $i++){

    

        $key = rand(0, count($num));

 

        $rand = $num[$key];



        $object_id .= $rand;



    }



    return $object_id;

    

} 

[Yorie]

Какие-то дикие решения:bm:
На мой взгляд два варианта:
- Подключиться к серверу из пыхи. Это можно сделать выделенным сокет-соединением или XML-RPC либой под Java или еще чем-нибудь. Отправить запрос и получить максимальный ObjectID. Хотя и это не особо хорошо, т.к. нет возможности синхронизировать процесс. Поэтому нужно отправлять серверу сразу запрос на создание нового предмета, чтобы сам сервер это сделал, а не пыхоскрипт;
- Писать максимальный ObjectId в какой-нибудь файл, либо в БД, при работе пыхоскрипта брать это значение. Шанс десинха тут минимален.

Первый вариант правильнее и предпочтительнее, но более затратен по реализации и требует определенных знаний.
А Ваши костыли с rand это имхобред, Рут прав, IdFactory сервера всегда начинает отсчет с максимального номера, так можно Long.MAX_VALUE забить за пару дней при достаточном онлайне. И потом, как сервер узнает, что увеличился ObjectId? Т.е. пока он не рестартнулся он будет продолжать считать, допустим, от 100. А Вы создали предмет с ID = 999. В итоге, когда сервер дойдет до 999 получите exception с дублированным ID и чья-то выбитая эпик бижа уйдет в небытие оперативной памяти :redlol:

[linliss]

Какие-то дикие решения:bm:
На мой взгляд два варианта:
- Подключиться к серверу из пыхи. Это можно сделать выделенным сокет-соединением или XML-RPC либой под Java или еще чем-нибудь. Отправить запрос и получить максимальный ObjectID. Хотя и это не особо хорошо, т.к. нет возможности синхронизировать процесс.
- Писать максимальный ObjectId в какой-нибудь файл, либо в БД, при работе пыхоскрипта брать это значение. Шанс десинха тут минимален.

все равно наступит момент(причем не 1 раз), когда серверу понадобится этот ид и начнется веселье:redlol:

Поэтому нужно отправлять серверу сразу запрос на создание нового предмета, чтобы сам сервер это сделал, а не пыхоскрипт;

это и есть самое правильное решение(как на офе)

[x3k]

А Ваши костыли с rand это имхобред

Спасибо, Кэп :ep: