MMOLDB is a publicly queryable SQL database for MMOLB games inspired by the Blaseball datablase. It's still in early development.
You can connect to the MMOLDB database using any Postgresql query tool (pgAdmin is a popular choice). Connect using these settings:
mmoldb.beiju.me. Do not add http
or https — the connection uses a different protocol.
42416
mmoldb
guest
moldybees
All other settings you should be able to leave at their defaults.
To connect using pgAdmin, go to the Query Tool Workspace (the second icon down at the very left of the screen) and input these connection settings.
Note: MMOLDB already has a lot of data, and as I'm writing
this it's only season 2. For your sake and my server's, I suggest
using low limits on your queries as you're debugging them.
It'll make your results load faster and reduce the load on the server.
Just don't forget to take it off before getting your final results.
Huge thanks to Astrid for Chron, without which none of this would be possible.
Another huge thanks to WoofyJack for mmolb_parsing, without which MMOLDB
updates would be much slower.
Contributors (project lifetime): WoofyJack, Ifhbiff, Centritide.
Reinstates data.player_versions_extended with the following changes:
priority, xp, level, and name_suffix columns. In particular,
note that building a player's full name from their
player_versions_extended row has changed. This will affect any queries
that correlate player versions with game events.greater_boon, greater_boon_id, lesser_boon, and
lesser_boon_id columns, as players can now have multiple of each.
Instead, those boons are in modification_ids and modifications, as well
as the new modification_types which tells you whether this modification
is a boon. Note that boons have always been just a special category of
modifications.Further changes may come to data.player_versions_extended later on, for
example to add support for more than just base stars in attributes and/or
player pitch type information.
Adds a utility function player_full_name which builds a player's full name
from a data.player_versions row, a data.player_versions_extended row, or
a first name, last name, and name suffix as three separate arguments. This
function will be kept up to date with any changes to player name rendering,
such as the addition of name_suffix in Season 10.
If you don't keep up with the staging server, also take a look at the next two sections of changelogs, since those changes will be new to you as well.
level to data.player_versions, along with several columns that are
meant for MMOLDB internal use. See docs for details.data.player_pitch_type_bonus_versions and
data.player_pitch_category_bonus_versions, which contain the information
you would think. See docs for details.taxa.pitch_category.category column to taxa.pitch_type.priority, xp, and name_suffix columns to data.player_versions.
See docs for details. In particular, note that building a player's full
name from their player_versions row has changed. This will affect any
queries that correlate player versions with game events.greater_boon and lesser_boon are removed from
data.player_versions, as you can now have multiple of each (at least
according to the API).data.player_modification_versions,
which has gained a new column, modification_type, to indicate whether
this modification is a greater boon, a lesser boon, or neither.taxa.modification_type to support the above change.data.door_prize_items: prefix, suffix, discarded_item_prefix,
and discarded_item_suffix.data.consumption_contests: batting_team_prize_prefix,
batting_team_prize_suffix, defending_team_prize_prefix, and
defending_team_prize_suffix.quote
column of data.player_report_versions is now nullable, and will be null
for any player versions in s10 and later. The overall structure of player
reports remains the same, even though "reports" aren't a discrete concept
any more, for backwards compatibility.data.player_pitch_type_versions with information on the
player's pitch types and frequency. Pitch type and pitch category bonuses
are not yet available. Let us know in the MMOLDB discord channel if you
want to use these bonuses so we know to prioritize that work.durability, prefix_position_type, and specialized columns to
data.player_equipment_versions. See docs for details.tier column to data.player_equipment_effect_versions. See docs
for details.data.events_extended until it realizes that home_run_distance existsdata.wither, data.efflorescence, data.efflorescence_growth,
and data.failed_ejections. See docs. (data.wither was added a while ago,
but wasn't added to the changelog at the time.)
data.wither, player_position was renamed to player_slot and
struggle_event_index was renamed to attempt_event_index.home_run_distance to data.event.info.raw_events is now a view into data.entities. As a consequence,
game_id is no longer available. Use mmolb_game_id to join on instead.
data.games provides the mapping from game_id to mmolb_game_id.stars in data.player_report_attribute_versions to base_stars and
add base_total, modified_stars, and modified_total. See the docs for
details. (This change is from a while ago, but wasn't added to the changelog
at the time.)full_location and abbreviation have been removed from the MMOLB API.
Those columns are now nullable in data.team_versions and will be null for
all versions going forward. (This change is from a while ago, but wasn't added
to the changelog at the time.)data.team_feed_versions and
data.player_feed_versions tables. Those were for internal use and didn't
have anything useful in them anyway.taxa.attribute_effect_type value Additive (short for
"additive multiplier") has been renamed to its now-known name Multiplier.
The speculative Multiplicative value (short for "multiplicative
multiplier") has been removed until its actual name is known.data.player_versions_extendeddata.player_versions_extended and its
documentation. Big thanks to Ifhbiff for a doing a lot of work creating and
documenting this view.data.player_report_attribute_versions and
data.player_equipment_effect_versions getting corrupted when the equipment
slot is cleared / when the report is removed.data.team_games_played with the feed events for games ending. This is
primarily useful for the timestamp. It can be used to find the proper team
and player versions to use for a given game. It is not necessarily guaranteed
that every game has an entry in team_games_played.data.events_extended view with a some useful fields for events,
including game_end_timestamp derived from team_games_played.data.defense_outcomes and data.offense_outcomes materialized views,
with a count of occurrences of each event type broken down by season, league,
and fielding position. I would also like to break it down by day type
(Regular season/Postseason/Superstar/Special event/Kumite/Offseason), but
MMOLB has been inconsistent about how days are notated so that will require
some special care. These are currently not documented on the Docs page.fair_ball_fielder_name to data.events?season=season to the URL.data.player_report_attributes and replace it with
data.player_report_versions and data.player_report_attribute_versions.
These use the same valid_from and valid_until system that other
_versions tables do, reflecting the fact that player reports are now
live-updating. This also adds recording of clubhouse talk quotes, which were
previously not in the database.data.games for info.data.modificationsdata.player_versionsdata.player_modification_versionsdata.player_equipment_versionsdata.player_equipment_effect_versionsdata.player_feed_versionsdata.player_attribute_augmentsdata.player_recompositionsdata.player_paradigm_shiftsdata.player_report_attributesdata.games.data.events, but we
plan to move to storing them in a child table like Weather.Known issues:
hit_base for home runs being Third for some reasonstrikes_before columntaxa.base column bases_achieved from bigint to int again? I swear
I did that in the last big update.abbreviation to taxa.pitch_type.taxa.hit_type. Changed data.events column hit_type
to reference taxa.base instead and renamed it to hit_base.taxa.base column bases_achieved from bigint to int. It never
should have been a bigint in the first place.taxa, data, and info schemata.home_team_id and away_team_id to home_team_mmolb_id
and away_team_mmolb_id in data.games.count_strikes and count_balls, which used to store the
count after the event finished, which also means that it stored 0-0 for every
PA-ending event.strikes_before and balls_before, which store the count at the
beginning of the event. The count at the end of the event can be easily
computed, and examples are included in the documentation.away_* and home_* fields to put away first.