Вход
Регистрация
Оригинал
Мой перевод
В течении долгих лет промышленники были вынуждены вручную перелопачивать кучу чертежей, что бы найти среди копий бесценные оригиналы.
Эта история о том, как мы помогли им.
Перво наперво: Почему они с самого начала не выглядели по разному?
Проблема была в том, что идентификаторы (ID) в нашей системе инвента были одинаковы; блюпринты, которые делали Огров ("Ogres") или Тораксов("Thoraxes") имели одинаковый идентификатор, вне зависимости от того что это, БПО или БПК. Конечно наши таблицы содержали поле тип, но эти атрибуты не хранились в тех же таблицах. Такие атрибуты хранились в специальных таблицах, например в Науке и Производстве (Science and Industry (S&I)) подсистемной таблице в случае с чертежами (blueprints).
Когда вы запрашиваете лист предметов в определенной локации из системы инвента, всё что вы получите - это только "общие атрибуты" атрибуты предметов без более специфичной информации. Таким образом БПО и БПЦ имеют одинаковые базовые атрибуты, в частности для получения параметра "тип" клиенту пришлось бы сделать еще один запрос к серверу (в S&I подсистему) что бы выяснить где оригиналы, а где копии. И именно так же обстояли дела, при нажатии на "показать информацию".
Мы не хотели, что бы вы так жестоко обращались с нашим маленьким милым сервером, когда открывали бы ангар полный чертежей и копий. Это просто ужасное решение, с учетом того, что большее время доп. информация не требуется. Мы так же не хотели создавать условно-объединенные (видимо что то вроде left outer join в mysql. Прим. переводчика.) таблицы каждый раз для отображения содержимого ваших ангаров. Это называется SQL-терроризмЪ!
Так как же так замечательно получилось, что появилась возможность различать БПО и БПЦ без приченения вреда БД?!
Первые шаги мы сделали еще при разработке тираниса с переводом на 64битную разрядность хранения предметов, о котором вы можете почитать в девблоге "64 бита должно хватить всем!". Хотя тот фокус был сделан не совсем для сабжа, но тогда мы сделали отличный шаг с запасом. Мы изменили тип данных в столбце идентификатора, объединили пару столбцов и подчистили устаревшие колонки. Последнее - очень важно! Мы обратили внимание, что столбец 'singleton' (адын) не был частью стека итем айди и мы заюзали его в качестве внешнего ключа. Мы так же зающали поле не отрицательное поле 'quantity' в котором указывалось сколько итемов хранится в стеке. Некоторые из вас возможно заметили, что это взаимоисключающие действия. Singletons должны иметь quantity 1 и что либо с quantity > 1 не может быть singleton (quantity в 1 так же входит в singleton).
Итак, мы решили массово обновить таблицы, проставив всем записям с параметром "singleton" "quantity" = 1, освободив и облегчив таким образом работу БД.
Следующий шаг был сделан в Incursion 1.3, подробности которого вы можете прочитать тут(не нашел перевода сего девблога на еверукоме. Ссылка на инглиш текст. Прим. переводчика.). Это стало продолжение предыдущего этапа, но тут мы чистили особенности, сделали несколько улучшений в защите от эксплойтов и заново ввели поле 'singleton' в структуры БД, но на этот раз как виртуальную колонку. Виртуальная колонка выглядит как обычная для программистов (Ложь. Только если расценивать программиста как человека разбирающего резалтсеты, но не пишущего хранимок и не имеющего отношения к структуре БД. Прим. переовдчика.), на самом деле в ней хранится не значение, а функция, значение которой определяется по другим признакам.
Объединив эти 2 изменения и получив 30битный простор отрицательных значений для зашифровки специальной информации для "singletons" и создали упрощенные (стандартизированные) методы обращения к ним. Мы использовали эти факты и смогли зашифровать отличие оригиналов от копий в сие поле (quantity) (омг, ИНКАПСУЛЯЦИЮ СЮДА!!! прим. переводчика.) как -1 для оригиналов и -2 для копий.
Итак, теперь клиент сразу получает в наборе данных эти параметры как 1 и 2 (мы не возвращаем отрицательные параметры
) и может спокойно различать БПЦ и БПО не совершая дополнительных обращений к БД.
Выпендрились, правда?
Теперь у нас есть бэкэнд сортировка БПЦ и БПО по "singleton" фрагу, т.е. у нас уже все готово, не так ли?
Нифига. Это теперь отлично работает в вашем ангаре, в багажнике индуса или в специальном каргохолде, т.к. туда направляются флаги различий. Но что ж теперь делать с местами, куда такие флаги не направляются, например ЛПшоп? Там у нас нет реального итема и нет соответсвующей записи о чертеже в таблицах поддержки о том, какой чертеж будет создан. В данном случае нам несомненно помогло то, что в LP Store есть только БПЦ, а метаданные мы могли получать по описанию несуществующего четрежа, что бы отобразить информацию о нем, как о существующем объекте.
Так и что я получил то в конце концов?
Так как мы теперь имеем 2 очень разные по форме вещи, с отдельными иконками, отдельными метаданными, мы можем вводить больше отдельных спец. классов функций. В каждом месте они теперь будет не просто выглядеть по разному, но и иметь различную функциональность. И по этому сейчас тыкая на иконку копии вы уже ждете, что вам отобразится соответсвующая функциональность. До этого вы не смогли бы получить эту информацию таким простым методом, как просто посмотреть как это выглядит. Но спецуевые поля обрабатываются на стороне клиента не дозапрашивая информации у сервера, что позволяет сделать общение с БД более дружественным, что очень важно в такой большой ММО игре.
Конечным результатом всех этих трудов стал Incursion 1.5.
Это была сложная работа, в ней принимало участи куча народу, было развернуто в 3 подхода, но теперь, наконец таки, вы можете визуально отличить БПО от БПЦ!
И теперь вы знаете как!
Эта история о том, как мы помогли им.
Перво наперво: Почему они с самого начала не выглядели по разному?
Проблема была в том, что идентификаторы (ID) в нашей системе инвента были одинаковы; блюпринты, которые делали Огров ("Ogres") или Тораксов("Thoraxes") имели одинаковый идентификатор, вне зависимости от того что это, БПО или БПК. Конечно наши таблицы содержали поле тип, но эти атрибуты не хранились в тех же таблицах. Такие атрибуты хранились в специальных таблицах, например в Науке и Производстве (Science and Industry (S&I)) подсистемной таблице в случае с чертежами (blueprints).
Когда вы запрашиваете лист предметов в определенной локации из системы инвента, всё что вы получите - это только "общие атрибуты" атрибуты предметов без более специфичной информации. Таким образом БПО и БПЦ имеют одинаковые базовые атрибуты, в частности для получения параметра "тип" клиенту пришлось бы сделать еще один запрос к серверу (в S&I подсистему) что бы выяснить где оригиналы, а где копии. И именно так же обстояли дела, при нажатии на "показать информацию".
Мы не хотели, что бы вы так жестоко обращались с нашим маленьким милым сервером, когда открывали бы ангар полный чертежей и копий. Это просто ужасное решение, с учетом того, что большее время доп. информация не требуется. Мы так же не хотели создавать условно-объединенные (видимо что то вроде left outer join в mysql. Прим. переводчика.) таблицы каждый раз для отображения содержимого ваших ангаров. Это называется SQL-терроризмЪ!
Так как же так замечательно получилось, что появилась возможность различать БПО и БПЦ без приченения вреда БД?!
Первые шаги мы сделали еще при разработке тираниса с переводом на 64битную разрядность хранения предметов, о котором вы можете почитать в девблоге "64 бита должно хватить всем!". Хотя тот фокус был сделан не совсем для сабжа, но тогда мы сделали отличный шаг с запасом. Мы изменили тип данных в столбце идентификатора, объединили пару столбцов и подчистили устаревшие колонки. Последнее - очень важно! Мы обратили внимание, что столбец 'singleton' (адын) не был частью стека итем айди и мы заюзали его в качестве внешнего ключа. Мы так же зающали поле не отрицательное поле 'quantity' в котором указывалось сколько итемов хранится в стеке. Некоторые из вас возможно заметили, что это взаимоисключающие действия. Singletons должны иметь quantity 1 и что либо с quantity > 1 не может быть singleton (quantity в 1 так же входит в singleton).
Итак, мы решили массово обновить таблицы, проставив всем записям с параметром "singleton" "quantity" = 1, освободив и облегчив таким образом работу БД.
Следующий шаг был сделан в Incursion 1.3, подробности которого вы можете прочитать тут(не нашел перевода сего девблога на еверукоме. Ссылка на инглиш текст. Прим. переводчика.). Это стало продолжение предыдущего этапа, но тут мы чистили особенности, сделали несколько улучшений в защите от эксплойтов и заново ввели поле 'singleton' в структуры БД, но на этот раз как виртуальную колонку. Виртуальная колонка выглядит как обычная для программистов (Ложь. Только если расценивать программиста как человека разбирающего резалтсеты, но не пишущего хранимок и не имеющего отношения к структуре БД. Прим. переовдчика.), на самом деле в ней хранится не значение, а функция, значение которой определяется по другим признакам.
Объединив эти 2 изменения и получив 30битный простор отрицательных значений для зашифровки специальной информации для "singletons" и создали упрощенные (стандартизированные) методы обращения к ним. Мы использовали эти факты и смогли зашифровать отличие оригиналов от копий в сие поле (quantity) (омг, ИНКАПСУЛЯЦИЮ СЮДА!!! прим. переводчика.) как -1 для оригиналов и -2 для копий.
Итак, теперь клиент сразу получает в наборе данных эти параметры как 1 и 2 (мы не возвращаем отрицательные параметры
) и может спокойно различать БПЦ и БПО не совершая дополнительных обращений к БД.Выпендрились, правда?
Теперь у нас есть бэкэнд сортировка БПЦ и БПО по "singleton" фрагу, т.е. у нас уже все готово, не так ли?
Нифига. Это теперь отлично работает в вашем ангаре, в багажнике индуса или в специальном каргохолде, т.к. туда направляются флаги различий. Но что ж теперь делать с местами, куда такие флаги не направляются, например ЛПшоп? Там у нас нет реального итема и нет соответсвующей записи о чертеже в таблицах поддержки о том, какой чертеж будет создан. В данном случае нам несомненно помогло то, что в LP Store есть только БПЦ, а метаданные мы могли получать по описанию несуществующего четрежа, что бы отобразить информацию о нем, как о существующем объекте.
Так и что я получил то в конце концов?
Так как мы теперь имеем 2 очень разные по форме вещи, с отдельными иконками, отдельными метаданными, мы можем вводить больше отдельных спец. классов функций. В каждом месте они теперь будет не просто выглядеть по разному, но и иметь различную функциональность. И по этому сейчас тыкая на иконку копии вы уже ждете, что вам отобразится соответсвующая функциональность. До этого вы не смогли бы получить эту информацию таким простым методом, как просто посмотреть как это выглядит. Но спецуевые поля обрабатываются на стороне клиента не дозапрашивая информации у сервера, что позволяет сделать общение с БД более дружественным, что очень важно в такой большой ММО игре.
Конечным результатом всех этих трудов стал Incursion 1.5.
Это была сложная работа, в ней принимало участи куча народу, было развернуто в 3 подхода, но теперь, наконец таки, вы можете визуально отличить БПО от БПЦ!
И теперь вы знаете как!
Официальный перевод
Оригинал
На протяжении многих лет промышленники EVEOnlineстрадали от невозможности быстро найти оригиналы ценных чертежей среди многочисленных копий.
Эта статья посвящена тому, как нам удалось исправить положение.
Начнем сначала: почему копии и оригиналы вообще выглядели одинаково?
Проблема заключалась в способе указания идентификаторов типа (typeID) в нашей системе учета объектов: чертеж, например, чертеж «Ogre» или «Thorax» обладал определенным идентификатором типа вне зависимости от того, являлся ли он оригиналом (BPO) или копией (BPC) ― и этот идентификатор задавал производимый с помощью этого чертежа предмет. Идентификаторы типа входят в таблицу учета предметов в игре (и каждый предмет обладает своим идентификатором) ― но характеристики данного типа предметов хранятся в отдельных таблицах (в случае чертежей ― в таблице «ScienceandIndustry»).
Когда игровой клиент запрашивает список объектов у системы учета, он получает лишь базовый перечень характеристик предметов, а не информацию из упомянутых выше таблиц. Базовые характеристики (в частности, идентификаторы) оригиналов и копий чертежей одинаковы, и поэтому для того, чтобы узнать, с чем именно игрок имеет дело, клиенту приходилось еще один раз обращаться к серверу (к таблице «ScienceandIndustry»). Именно это и происходило при выполнении команды «Показать информацию» для чертежа.
При этом совершать дополнительный запрос каждый раз, когда игрок открывает ангар с чертежами, было бы просто жестоко по отношению к серверу ― ведь в большинстве случаев эта информация избыточна. Это, мягко скажем, не очень хорошо и с точки зрения работы с базой данных.
Так как же нам удалось решить эту проблему без отрицательных последствий для базы данных и сервера?
Первый шаг был сделан с выходом обновления Tyrannis1.2в конце прошлого года (дополнительная информация ― в статье «64 bitsshouldbeenoughforeverybody» ). Хотя основная часть работы была посвящена переходу на 64-битные идентификаторы в системе учета предметов, мы этим не ограничились. Мы изменили структуру таблицы объектов, увеличили количество битов в идентификаторах и других элементах таблицы, удалили один устаревший атрибут и объединили еще два. Последний момент особенно важен в контексте данной статьи. Раньше в базе данных существовало поле “singleton” («одиночка») типа «бит»; оно указывало, что данный объект не является частью группы предметов, и что его идентификатор может использоваться в других таблицах. Второе поле, «количество», определяло количество находящихся в группе предметов. Легко видеть, что значения этих полей взаимоисключающи. Объекты-«одиночки» должны входить в группу, состоящую только из одного предмета, а группа из более чем одного объекта не может являться «одиночкой» (при этом стоит отметить, что группа из одного предмета не обязательно является «одиночкой»).
Чтобы сохранить место в базе данных (и обеспечить быстродействие игры), эти поля были объединены в новое поле типа «integer» (целое число) ― при этом объекты, для которых значение этого поля является отрицательным, считаются «одиночками». Чтобы перейти от старой системы к новой, достаточно было заменить все значения «singleton==1» на «quantity=-1».
Следующий шаг мы сделали, выпустив обновление Incursion1.3(дополнительная информация – в статье «Inventorycorificationpart2 - creationofCARBONInventory». Мы продолжили начатую в ходе предыдущего этапа работу, ввели ряд мер, направленных на борьбу с читерами, упростили внутренний интерфейс для работы с системой объектов ― А ТАКЖЕ добавили поле «одиночка» в структуру данных DBRow, но на этот раз в качестве виртуального поля. С точки зрения программирования виртуальное поле выглядит точно так же, как и обычное, но обращение к нему происходит с помощью специальной функции (которая в нашем случае принимает в качестве исходных данных и значение поля «количество»).
В результате этих изменений мы получили 30-битный диапазон (для отрицательного значения этого поля), где можно хранить различную информацию в зависимости от типа объекта, а также единый способ доступа к ней. Если говорить о чертежах, то для оригиналов значение поля «качество» стало равным -1, а для копий ― -2.
Итак, теперь в том случае, если объект является чертежом, игровой клиент может проверять значение виртуального поля «одиночка» и отображать соответствующую иконку в зависимости от того, оригинал ли это или копия. При этом не осуществляются дополнительные запросы к серверу и не создается лишняя нагрузка на базу данных.
Изящно, не так ли?
Но, к сожалению, этого недостаточно.
Данный метод хорошо работает при отображении оригиналов и копий чертежей в вашем ангаре ― ведь мы знаем значение флага «одиночка». Но что делать, если объекта еще не существует (как, например, в случае с чертежами в магазине наград)? Ведь если предмета физически нет в игре, то и данные в соответствующих дополнительных таблицах отсутствуют. В данном случае проблема решается просто: мы знаем, что в магазине наград продаются только копии чертежей, а необходимая информация (количество партий и качество) хранится в структуре конкретного предложения. Эту информацию мы и передаем игровому клиенту, когда вы запрашиваете информацию о еще несуществующем чертеже.
Итак, о чем это я?
Так как теперь у нас в игре есть тип объекта, который может существовать в двух различных формах, с разными иконками и различными метаданными, нам пришлось начать обрабатывать множество граничных случаев для этого типа. Практически во всех случаях, когда эти иконки появляются в игре, мы отдельно обрабатываем информацию, необходимую не только для их отображения, но и для открытия окна «Показать информацию». Но при этом этот код исполняется клиентом игры и не создает дополнительную нагрузку на сервер.
Результат этой работы вы можете наблюдать в игре после выхода обновления Incursion1.5.
В работе над этим нововведением участвовало множество людей, его выход потребовал трех обновлений игры ― но теперь вы наконец можете на глаз отличить оригинал чертежа от его копии.
А благодаря этой статье вы знаете, как именно мы этого добились.
Сообщение отредактировал Chegevarich: 03 June 2011 - 19:40
Наверх
