Publish rate base table in DB

[cmgosnell]

why?

bc we have these cool tables that have now been vetted (via #3534) and they should be accessible in the db

success?

• rate base table is being published and distributed.
• this table has sufficient but not overwhelming documentation to explain their weirdness. Focus on how a user would use these tables not on how they were built.
• Potential rabbit hole avoid-er: Don't publish the out_ferc1__detailed_* tables. Only publish out_ferc1__yearly_rate_base 🟢 -> I spun off the detailed table into Publish detailed accounting tables in DB #3642

how?

out_ferc1__yearly_rate_base

Beta Give feedback

1. make draft schema
2. check pks (as asset_checks when needed bc nulls)
3. document table
4. document new columns
5. convert draft schema into real schema
6. convert asset to sql asset
7. migrate full db schema
8. add release notes!

found oddities

Beta Give feedback

1. the column tags_in_rate_base shouldn't end up in the rate base table bc == "yes". but we just converted two tags prop checks into asset checks that rely on that column. Need to slurp these checks back into the asset function.
2. the pk of the table (which is full of nulls so it can't be a real pk) -> made asset_check instead

possible tweaks to make this easier to document

Beta Give feedback

1. remove tags_ prefix? - Idk i think this is fine. its helpful to be able to say "all of these are tags" so i think its okay as is even though its long
2. replace the augemented aggregatable_{dimension_column} columns with their og counterpart and document in the table description

[aesharpe]

remove tags_ prefix? - Idk i think this is fine. its helpful to be able to say "all of these are tags" so i think its okay as is even though its long

I was also sort of thinking this...but it's not a high priority. I think it would help if I understood the difference between these tags and the xbrl_factoids better.