I'm not sure I like the Project >> Environment >> Server >> Database hierarchy.
The way the check works doesn't make sense to me with the suggested categorization hierarchy.
If I have a project (P1), with an environment (Prod), a server (S1), and 3 databases (D1, D2, D3). All of these databases are part of the same project (P1).
Then another environment of (Dev) with the same databases on another server. I want to compare the respective Dev D1 to the respective Prod D1. That's how it logically organizes to me.
I add the databases that way and it will compare the schemas of D1, D2, D3. that's not what I want. If I'm going to compare schemas within the same "environment" categorization, then my "environment" category makes more sense as a project level category with my database Dev and Prod instances under it, so they can be compared.
My need is to track schema changes either from Dev to QA to Prod, or to track any schema change on Prod and be alerted it happened and who did it.
The current way it works isn't very useful for me.
We’re planning to improve the way you can organize database later this year. The current projects mechanism is limited. Please do leave us any comments with your thoughts on how we can make this better
Daniel S. commented
I think my comment is on the same thread but not 100% sure since we don't use projects here. What I would like to see is user-defined labels for the categories. Development, Integration, Testing, Acceptance & Production is very nice to have but since I am taking care of databases that belong to different companies I would love to be able to create my own labels and remove the pre-defined ones.
I would also like the possibility to hide empty categories in the overview.
We want to improve our projects concept - probably later this year.
The way we intended projects to be used is that you'd put one logical database into each project. In Justin's example D1, D2, D3 would all be in their own projects. That way you can see if the version of D1 that is in Dev is the same as the version of D1 that is in Prod. The name projects is pretty misleading (our bad!)
However using projects like this doesn't help you group your databases together into groups that make sense within your organization.
Thanks for the quick response time, definitely appreciated.