Не может не радовать, что
-
...
колчаны на оффе есть. потвоему клиент фанаты дорабатывают чтоли?Можно узнать - в каком они там месте спрятаны? Примерно...
А то я лазал-лазал и там их что-то не обнаружил...
Уточняю - я об русском оффе - который как раз Гравити поддерживается...
Мне просто интересно - насколько они там кривые - если Скронцу верить. -
Рус.офф отстает где-то на год-полтора от кРО, если не больше... у них ничего нет, так как "все" обещано вместе с введением оплаты... каменный век там короче :roll:
-
@4e6yp:
Рус.офф отстает где-то на год-полтора от кРО, если не больше... у них ничего нет, так как "все" обещано вместе с введением оплаты... каменный век там короче :roll:Как бы там ни было - на кРо иРо и какие еще там РО - вопрос тем не менее решен. И решен правильно.
А тут речь собственно давно уже об другом. Об ошибках в собственности Мотра. О неверной индикации элементального оружия в вендинге.
Давайте ближе к этому.
-
Данные выводятся из игры, так? Допустим, сейчас выводится только ID предмета. Чтобы реализовать отображение кованого оружия, нужно выводить что-то еще, кроме ID, т.к. по ID его определить нельзя. Это влечет за собой увеличение нагрузки при выводе, увеличение выводимых данных и следовательно время их обработки и сортировки, так? Так при чем тут SQL?
Полторы минуты - это время, в течение которого вендинг стат выдает неполную информацию (ввиду того что выведенные из игры данные обрабатываются или, если они обрабатываются сразу же, идет синхронизация).
-
Вот как отображается обычный магазинный фист:
1807,1,0,1,5,0,
Вот как отображается огненный фист:
1807,1,0,1,5,0,
Вот как отображается ледяной фист:
1807,1,0,1,5,0,
Вот как отображается земляной фист:
1807,1,0,1,5,0,Кто нить видит разницу?
Вот как отображается фист с картой фабре:
1807,1,4002,1,5,0,4002 это ID карты.
-
@Zeno:
Данные выводятся из игры, так? Допустим, сейчас выводится только ID предмета. Чтобы реализовать отображение кованого оружия, нужно выводить что-то еще, кроме ID, т.к. по ID его определить нельзя. Это влечет за собой увеличение нагрузки при выводе, увеличение выводимых данных и следовательно время их обработки и сортировки, так? Так при чем тут SQL?Притом тут SQL - что запрос выполняется практически одинаковое время. что с доп инфой что без нее. Во всяком случае - на порядок ничто не вырастет.
В общем - я так понимаю - что независимо от итогов обуждения - ответ простой: да - показывает неправильно, но нам делать ничего не охота несмотря ни на какие аргументы. Ну нет - так нет... Это тоже ответ.
-
Bububu, при join нескольких таблиц - одинаковое время?
С каких это пор? -
Bububu, при выдергивании элементов прийдется дергать еще одну таблицу... время обработки возрастет в 2 раза.
-
Да ладно все привыкли уже по цене отличать.
Да неудобно. Да подругому было бы лучше. Да можно было бы дергать еще одну таблицу и увеличить таймаут обновления с 5 до 10 минут как и написано на сайте.Но не смертельно же?
-
Shoki, таймаут прийдется увеличивать до 15 минут, при этом сейчас статистика недоступна минуты 2-3 а там будет 5-6...
-
@Vlad-V Drakula:
Bububu, при выдергивании элементов прийдется дергать еще одну таблицу... время обработки возрастет в 2 раза.Влад - я еще ни одного SQL-сервера не видел у которого из-за этого настолько бы выросло время ответа, хотя работаю с ними уже лет 10 по крайней мере... Записей о товарах на весь вендинг - всего 1500-1700 штук формируется о разных товарах и обо всех продавцах... И таблиц для этого сканируется и обрабатывается сервером - намного больше чем одна - не думаю что я ошибусь сильно, если скажу что как минимум 10-15 разных таблиц в этом участвует. Так что не надо вот таких надуманных оценок - еще одна таблица - значит время вырастет в 2 раза... Чепуха это. SQL - он собс-на для того и был создан чтобы ускорять такие операции - по выборке инфы из множества таблиц.
Cобственно - смысла теории разводить нет особого. Пожелание высказано. Сложность его понятна. Дело только за командой поддержки и ее желания учесть это пожелание. Вот и все. Ответ команды - в принципе уже почти ясен, т.к. никто из лиц официальных здесь не отписался. Так что - скорее всего - ответ нет
Что же до моего мнения и умения работать с таблицами и SQL-запрсами, а так же с учетом моего представления о структуре таблиц в игре - то никакого существенного замедления быть не должно вообще, если таблица вендинга строится правильно. Но сервер содержу не я и всех его особенностей не знаю.
-
Bububu, ладно, поясню...
Для начала сделует учесть, что выборка идет не из SQL сервера, данные о трейдах держит мап-сервер, при трейде он же осуществляет трансакцию в SQL, причем отложенную, оттого и откаты бывают до 5-ти минут если мап рухнул.
Второе - мап-сервера и так нагружены по самое "не могу" и заставлять их выдавать еще и дополнительные параметры это лишняя нагрузка как на сам мап-сервер так и на сокеты которые работают с конечной скоростью.
Надеюсь не соврал, так как реализация подобного на мотр может несколько отличатся от того, что видел я, но общий смысл уловить я думаю можно...
-
@Vlad-V Drakula:
Bububu, ладно, поясню...Для начала сделует учесть, что выборка идет не из SQL сервера, данные о трейдах держит мап-сервер, при трейде он же осуществляет трансакцию в SQL, причем отложенную, оттого и откаты бывают до 5-ти минут если мап рухнул.
Второе - мап-сервера и так нагружены по самое "не могу" и заставлять их выдавать еще и дополнительные параметры это лишняя нагрузка как на сам мап-сервер так и на сокеты которые работают с конечной скоростью.
Надеюсь не соврал, так как реализация подобного на мотр может несколько отличатся от того, что видел я, но общий смысл уловить я думаю можно...
На это можно сказать только то, что когда-то говорил Королев (главный конструктор ракет и спутников - если ты не знаешь...):
" Люди делятся на две основные категории: 1 - ищет способы решить поставленную задачу, 2-я - ищет причины по которым не могут решить поставленную задачу..."И больше - можно ничего тут уже не обсуждать.
Собственно - основное это иметь желание сделать по человечески. Если же его нет - всегда найдется миллион причин и трудностей тоже... Забей короче... -
Bububu, да мне в общем пофиг
я могу флудить из чистой любви к флуду... хочешь расскажу почему нельзя делать выборку непосредственно из SQL? -
@Vlad-V Drakula:
Bububu, да мне в общем пофиг :lol: я могу флудить из чистой любви к флуду... хочешь расскажу почему нельзя делать выборку непосредственно из SQL? :lol:Ты мне лучше расскажи - как правильно писать буквы и составлять слова из них... Это было бы забавно :lol:
Только тему для этого открой отдельную.
-
да полезно бы было бы полюбак
-
Раз в 10 минут скрипт проходит и собирает инфу с торгашей, т.е. из таблиц вендинга ... на винте они или в оперативке это не суть и на каком серваке тоже всеравно, там объем данных то плевый на самом деле.
Далее создается временная таблица (на самом менее загруженом серваке наверное) по результатам и к ней обращаются юзеры через веб.
Мне кажеться сделано так, и я бы сделал так.Утверждения об одном выбираемом ай-ди... ла-ла-ла - лишены логики и знаний. По ай-ди "можно узнать" вид оружия, заточку, слотовость и вставленые карты только если они вшиты в айди...например первые 3 цифры ай-ди типа оружия, далее цифра кол-ва слотов, потом по 3 цифры на каждую карту ... но этого в наших ай-дишниках вроде-бы нет
И при этом никто не мешает добавить ещё 1 символ для элемента) может ещё один для определения вввс ввс вс или без вс. Хотя это все и в одну циферьку легко помещается). Ну и в конце 5-7 цифр чтоб отличить от один ввс файр стунер от другого такого-же.Если этого "вшития" нет,- то всеравно нужен ещё запрос или join (ну или это все, как и должно, хранится в одной таблице, с.м. далее).
Мне кажеться у нас сделано по другому, есть ай-ди который уникально определяет "нечто" в таблице, а в этой таблицы уже есть поля где указан тип оружия, заточка, слотовость, элемент, карты и т.д. Т.е. самая стандартная схема.
Хранить элементы в другой таблице... не вижу смысла. Особого культа 3 нормальной формы я не встречал. Никому не нужен лишний join в запросе. Соответственно храним элемент в той-же таблице, даже без вопросов. Денормализация рулит, 5мегбайтные винты в далеком прошлом, экономить байты нет смысла, а вот вычислительные мощности никогда не бывают лишними в серьёзных проектах.
А "непосредственно из sql" выборку надо делать всегда. Ничего быстрее, чем хорошая sql база - нет. Хорошая база SQL работает быстрее, чем открытие файла, хоть все данные и храняться в файлах
Просто базы обладают продвинутым (очень) кешем. И кроме того самые "горячие" данные можно целиком хранить в таблицах записанных в оперативку. Ничего быстрее быть не может. Поэтому выбираем из SQL всегда. Любые промежуточные варианты затормозят сервак. Хотя я может что-то и упустил, но сильно сомневаюсь.Просто мини ликбез, для тех кому интересно ... а то тут перепалка не серьёзная).
-
...
Просто мини ликбез, для тех кому интересно ... а то тут перепалка не серьёзная).Во первых - нефих работать археологом - забей уже забыли...
Во-вторых - если занимаешься ликбезом - неплохо хотя бы минимально знать тему. А то я уж сбился со счета заявленных тобой глупостей - вроде сравнительных скоростей открытия файла и выборки из SQL-базы... :lol: -
ух встретился народ лоб в лоб)
скажу: если возможно организуйте пожалуйста)
-
@Найф:
ух встретился народ лоб в лоб)скажу: если возможно организуйте пожалуйста)
Дык - все давно уже сказали - да полезно и хорошо...
Тока вот скорее всего сделано не будет. И зачем собственно начинать новый круг обсуждений?
