MOTR logo
    • Категории
    • Последние
    • Популярные
    • Метки
    • Пользователи
    • Группы
    • Зарегистрироваться
    • Войти

    Не может не радовать, что

    Запланировано Прикреплена Закрыта Перенесена Общий
    42 Сообщения 21 Posters 3.5k Просмотры
    Загружаем больше сообщений
    • Сначала старые
    • Сначала новые
    • По количеству голосов
    Ответить
    • Ответить, создав новую тему
    Авторизуйтесь, чтобы ответить
    Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
    • BububuB Не в сети
      Bububu Заблокирован
      отредактировано

      @Vlad-V Drakula:
      Bububu, ладно, поясню...

      Для начала сделует учесть, что выборка идет не из SQL сервера, данные о трейдах держит мап-сервер, при трейде он же осуществляет трансакцию в SQL, причем отложенную, оттого и откаты бывают до 5-ти минут если мап рухнул.

      Второе - мап-сервера и так нагружены по самое "не могу" и заставлять их выдавать еще и дополнительные параметры это лишняя нагрузка как на сам мап-сервер так и на сокеты которые работают с конечной скоростью.

      Надеюсь не соврал, так как реализация подобного на мотр может несколько отличатся от того, что видел я, но общий смысл уловить я думаю можно...

      На это можно сказать только то, что когда-то говорил Королев (главный конструктор ракет и спутников - если ты не знаешь...):
      " Люди делятся на две основные категории: 1 - ищет способы решить поставленную задачу, 2-я - ищет причины по которым не могут решить поставленную задачу..."

      И больше - можно ничего тут уже не обсуждать. 😎 Собственно - основное это иметь желание сделать по человечески. Если же его нет - всегда найдется миллион причин и трудностей тоже... Забей короче...

      1 ответ Последний ответ Ответить Цитировать 0
      • Vlad V DrakulaV Не в сети
        Vlad V Drakula
        отредактировано

        Bububu, да мне в общем пофиг 🙂 я могу флудить из чистой любви к флуду... хочешь расскажу почему нельзя делать выборку непосредственно из SQL? 🙂

        1 ответ Последний ответ Ответить Цитировать 0
        • BububuB Не в сети
          Bububu Заблокирован
          отредактировано

          @Vlad-V Drakula:
          Bububu, да мне в общем пофиг :lol: я могу флудить из чистой любви к флуду... хочешь расскажу почему нельзя делать выборку непосредственно из SQL? :lol:

          Ты мне лучше расскажи - как правильно писать буквы и составлять слова из них... Это было бы забавно :lol:

          Только тему для этого открой отдельную.

          1 ответ Последний ответ Ответить Цитировать 0
          • PumaP Не в сети
            Puma
            отредактировано

            да полезно бы было бы полюбак

            1 ответ Последний ответ Ответить Цитировать 0
            • kuguK Не в сети
              kugu
              отредактировано

              Раз в 10 минут скрипт проходит и собирает инфу с торгашей, т.е. из таблиц вендинга ... на винте они или в оперативке это не суть и на каком серваке тоже всеравно, там объем данных то плевый на самом деле.
              Далее создается временная таблица (на самом менее загруженом серваке наверное) по результатам и к ней обращаются юзеры через веб.
              Мне кажеться сделано так, и я бы сделал так.

              Утверждения об одном выбираемом ай-ди... ла-ла-ла - лишены логики и знаний. По ай-ди "можно узнать" вид оружия, заточку, слотовость и вставленые карты только если они вшиты в айди...например первые 3 цифры ай-ди типа оружия, далее цифра кол-ва слотов, потом по 3 цифры на каждую карту ... но этого в наших ай-дишниках вроде-бы нет 😃 И при этом никто не мешает добавить ещё 1 символ для элемента) может ещё один для определения вввс ввс вс или без вс. Хотя это все и в одну циферьку легко помещается). Ну и в конце 5-7 цифр чтоб отличить от один ввс файр стунер от другого такого-же.

              Если этого "вшития" нет,- то всеравно нужен ещё запрос или join (ну или это все, как и должно, хранится в одной таблице, с.м. далее).

              Мне кажеться у нас сделано по другому, есть ай-ди который уникально определяет "нечто" в таблице, а в этой таблицы уже есть поля где указан тип оружия, заточка, слотовость, элемент, карты и т.д. Т.е. самая стандартная схема.

              Хранить элементы в другой таблице... не вижу смысла. Особого культа 3 нормальной формы я не встречал. Никому не нужен лишний join в запросе. Соответственно храним элемент в той-же таблице, даже без вопросов. Денормализация рулит, 5мегбайтные винты в далеком прошлом, экономить байты нет смысла, а вот вычислительные мощности никогда не бывают лишними в серьёзных проектах.

              А "непосредственно из sql" выборку надо делать всегда. Ничего быстрее, чем хорошая sql база - нет. Хорошая база SQL работает быстрее, чем открытие файла, хоть все данные и храняться в файлах 😃 Просто базы обладают продвинутым (очень) кешем. И кроме того самые "горячие" данные можно целиком хранить в таблицах записанных в оперативку. Ничего быстрее быть не может. Поэтому выбираем из SQL всегда. Любые промежуточные варианты затормозят сервак. Хотя я может что-то и упустил, но сильно сомневаюсь.

              Просто мини ликбез, для тех кому интересно ... а то тут перепалка не серьёзная).

              1 ответ Последний ответ Ответить Цитировать 0
              • BububuB Не в сети
                Bububu Заблокирован
                отредактировано

                @kugu:

                ...
                Просто мини ликбез, для тех кому интересно ... а то тут перепалка не серьёзная).

                Во первых - нефих работать археологом - забей уже забыли...
                Во-вторых - если занимаешься ликбезом - неплохо хотя бы минимально знать тему. А то я уж сбился со счета заявленных тобой глупостей - вроде сравнительных скоростей открытия файла и выборки из SQL-базы... :lol:

                1 ответ Последний ответ Ответить Цитировать 0
                • НайфН Не в сети
                  Найф
                  отредактировано

                  ух встретился народ лоб в лоб)

                  скажу: если возможно организуйте пожалуйста)

                  1 ответ Последний ответ Ответить Цитировать 0
                  • BububuB Не в сети
                    Bububu Заблокирован
                    отредактировано

                    @Найф:
                    ух встретился народ лоб в лоб)

                    скажу: если возможно организуйте пожалуйста)

                    Дык - все давно уже сказали - да полезно и хорошо...
                    Тока вот скорее всего сделано не будет. И зачем собственно начинать новый круг обсуждений?

                    1 ответ Последний ответ Ответить Цитировать 0
                    • AmberA Не в сети
                      Amber
                      отредактировано

                      Забавно, господа. Все так увлеченно спорят и говорят где какие запросы надо выполнить - а кто-нибудь из участвовавших в обсуждении имеет ДОСТОВЕРНУЮ инфу о формате хранения данных об игровом мире? Не в стиле "я бы сделал так:....", а точную и достоверную инфу. А то я тоже могу заявить что все данные о Мире хранятся в bmp-файлах и с определенным шагом времени проводится распознование образов и их перезапись. И никто кроме админов это оспорить не сможет.

                      1 ответ Последний ответ Ответить Цитировать 0
                      • ShokiS Не в сети
                        Shoki
                        отредактировано

                        afaik эмулятор jAthena предлагает два варианта хранения данных - текстовые файлы и sql-совместимые субд. если выбран вариант с субд, то предполагаецца, что это будет mysql. при этом очень сильно вероятно что кроме mysql ничего не подойдет, но это не точно.

                        это можно узнать на sf.net/projects/jathena

                        1 ответ Последний ответ Ответить Цитировать 0
                        • Первое сообщение
                          Последнее сообщение