Мы используем два варианта инструментов для проведения тестов: тестирование на базе платформы Swrve (в играх интегрирован их SDK) и тестирование с помощью кастомной самописной системы. Последняя позволяет использовать более гибкие настройки для правил набора групп.
Что касается метрик, это всегда индивидуальный набор в зависимости от теста. Cмотрим распространённые kpi (revenue, arpu, arppu, retention, churn rate), а затем метрики специфические для исследуемого объекта (сложность/интерес — для уровней, частоту использования — для предметов, процент покрытия — для нововведений в игровой активности).
На вскидку 2-3 тысячи таблиц. Порядок записей, как я понял, следующий: подсхемы внутри модели отсортированы в лексикографическом порядке, таблицы — в порядке попадания в схемы. Соответственно в m7object вначале идут схемы, затем таблицы в указанном порядке, затем столбцы и прочие объекты в порядке соответствующем порядку их родительских объектов — это структура m7object. В таблице m7objectproperty содержится иерархическая система свойств и связей объектов друг с другом в порядке обхода m7object. Таким образом упрощённо в m7object объект с id = 1 — это схема, затем c id от 2 до какого-то n — подсхемы, далее таблицы, столбцы, макросы. А в m7objectproperty с 1 до m свойства модели, с m до m*n свойства подмоделей, далее свойства таблиц в том порядке в котором на них ссылаются подсхемы указанного промежутка от m до m*n.
Очень верно про 1 человека, который шарит. Это идеал. Однако проекты имеют свойство разрастаться. Если изначально разработкой занимались 2-3 программиста, потребности в выделенном человеке для контроля структур не было. Сейчас, когда в команде десяток человек — такой специалист очень даже нужен. Но брать со стороны и добиваться, чтобы он «въехал» в существующую хренову тучу таблиц и взаимосвязей — пока не получается, поэтому стараемся оптимизировать процесс, который уже имеется.
Почти верно, но мы храним ещё и логическую схему, кроме физической. В свою очередь логическая схема является частью документации, отсюда и централизация.
Что касается метрик, это всегда индивидуальный набор в зависимости от теста. Cмотрим распространённые kpi (revenue, arpu, arppu, retention, churn rate), а затем метрики специфические для исследуемого объекта (сложность/интерес — для уровней, частоту использования — для предметов, процент покрытия — для нововведений в игровой активности).