Issues with dbForge coming from MySQL Workbench
Posted: Thu 12 Dec 2019 23:31
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.
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.