1
If you are not seeing the changes in the business table after the compress, it may be due to the fact that the state ID's were not present in all versions, so they could not be dropped.
This article explains it better:
https://sspinnovations.com/blog/versioning-dummies-part-3-reconcile-post-and-compress-oh-my/
In summary:
In your reconcile script, you should reconcile and post only desired versions against their parent.
In other words, reconcile and post upwards in order of ancestry.
For example, a grandchild version will be reconciled and posted to their parent, NOT their grandparent.
Do the same until you reach the default version.
No compress yet.
Then, reconcile (no post) downwards from default in order of descendants.
Then compress.
2
Another solution may be to register the data as versioned with the option to move edits to base.
This will allow edits made to default (either directly to default or reconciled and posted into default) to be read directly by a SQL query without needing to compress.
The catch is that conflicts would not be detected and will be overwritten.
"When you edit the DEFAULT version or post a version to DEFAULT, you do not have the ability to resolve conflicts, so it is possible to overwrite another user's edits."
See:
http://desktop.arcgis.com/en/arcmap/10.4/manage-data/geodatabases/data-maintenance-strategies.htm
3
Versioning for Dummies part 5 discusses branch versioning, as opposed to traditional versioning.
https://sspinnovations.com/blog/versioning-dummies-pt-5-branch-versioning-utility-network/