Devart Forums

I've used MySQL Workbench (WB) on and off for years and decided to try dbForge Studio for MySQL.

There are a few core issues I'm having with dbForge I wanted to talk about (and receive feedback on).

1) dbForge's use of Projects doesn't make sense because the editor endorses developers to edit the live database objects rather than work on the project objects. This is very confusing since every other IDE I've used has the developer designing on the project side and then deploying that project accordingly (through forward engineer or synchronize). In dbF I get a really nice UI when editing a stored procedure on a connection, but in a project file, it's just code. It’s as if two separate products and teams were merged with inconsistent methodologies. As such, with dbF I can't find my "design origin" as it seems to be spread between both live database and project objects. With this approach, I am endorsed to work on a live local database, synch those changes to my project, build the project, and then deploy that product to our live RDS database. This goes against what I consider to be proper process of working from the project, deploying to test; testing, and then deploying to live, and then testing. The whole "working in the live connection environment" approach (which BTW is my local sandbox, but nonetheless a local live system) is highly concerning, and goes against the processes I've used for more than a decade. And with synchronization only pushing one direction, what happens when I make a change to the stored procedure on the local sandbox but then another change in the SQL file on the project explorer and then synch? I'm guaranteed to lose one of the changes. My experience has been the Project is ALWAYS the point of origin for development; with dbF it seems that is no longer the case. This opens the door for collisions and de-synchronization (per my example). I simply do not understand why dbF is endorsing live editing and requiring us to synch those live edits to the "core" project, which must act as the source for deploying to a production environment.

2) The Database Diagram tool. It only seems to work with a live connection and creates the table objects in real-time on the connection... this makes absolutely no sense to me at all; reaffirming the issue above (#1) and taking us further away from a project serving as the source of design. It's not design if it's pushing everything live at the time of creation and adjustment. So if I make design changes in the database diagram that’s part of my project… it updates the connection table (live) and doesn’t touch the table in the project (or add a new one) – I have to push/synchronize FROM the live database to my project to get changes when I'm designing tables and relationships. This makes even less sense to me than #1.

While I think the code editor and build/debug features of dbForge are awesome, I’m finding the above two issues to be highly concerning as they are preventing me from feeling comfortable as to the overall process of managing a code base and properly deploying/synchronizing it. Plus the issues just don’t make any sense to me; not just because I came from WB, but also MSSQL.

Feedback on these issues would be appreciated.

You can vote for the following suggestion on the UserVoice forum https://devart.uservoice.com/forums/225134-devart-general/suggestions/4616606-implement-the-database-diagram-functionality-that

We collect and analyze the information from this forum in order to make a proper roadmap for the future product releases.

This response is very disappointing. You ignored the first question entirely, and you pointed me to a "vote" for something that is standard for other tools. Do you really need to use a voting system to decide of database design and architecture should be done without requiring that database to be built in real-time? You realize that pretty much every DBA out there builds a new database infrastructure "offline" first before deploying it, correct?

Quite concerned by what I've seen here.

To provide additional details; in order for us to use dbForge to do any design work, we must work in the live sandbox environment; projects have been dropped completely for design work because the diagram only synchronizes with a live environment and any refactored changes are done in the live environment, so using the editor to modify project files guarantees conflicts. The only way to use the project files to design is to manually enter everything in via text with no interface. That's just not feasible in 2019.

As such, the project feature of dbForge is merely a temporary repository, and to use your product for design and deployment we must create a new project each time we want to deploy, synchronize our sandbox/local DB, build, then deploy, then delete the project.

This just outlines the extremely poor overall design nature of dbForge. While the actual syntax and debug features are solid, as well as the "live" database features, it's utterly tedious for a Database Designer to figure out how to properly use your tool to actually design and architect and then deploy and maintain a live database because dbForge fails to establish a "prime center" for design/development, and the requirement for the Data Diagram system to only function with a live database reaffirms the disconnection even more.

I would really like to see an official response from a developer on this issue, since it's a fundamental design flaw with the studio that really needs to be discussed and addressed. There are so many great features in dbForge Studio, but this complete disconnection from true design and development of Database Architecture and Infrastructure is a big issue. As mentioned, projects are pretty much useless due to the Database Diagrams requiring a live connection, which prohibits offline design and collaboration with the project system.