I use this to maintain three 'identical structured' environments:
- development environment (DEV)
- quality assurance / test environment (PQA)
- live environment (LIVE)
The only difference between the environments is the data that the tables contain.
Often, I made changes in the dev environment without documenting it in the conversion script. In that way I afterwards have to search which changes I made.
In my opinion a great HeidiSQL would be a 'table-structure-compare', that searches for changes between two tables, or more, maybe even between two entire databases.
The step after this compare feature would be a button to generate a update script ;-)
The compare part is easy anyway: you just need to get normalized SQL dumps of both databases (mysqldump or even HeidiSQL should be enough) and compare them with your favourite file compare tool (I use WinMerge but there're many to choose from).
I also work w/ different databases of equal structure (1 dev. and a few prod. DBs). Copying the ALTER TABLE statements from Heidi's SQL log into a changelog (w/ short comments) is not that hard.
"Copy line to new query tab" (context menu @ SQL log) is a neat feature: after doing so, just use another DB and alter it's table(s), too.
It is even possible to select the fields of the selected table, and compare it with a field with the same fieldname of the other table. Don't you all think?
The difficult part is creating the appropriate SQL statements to port changes. That's the key feature: without it, you need to duplicate manually any change you've detected. And no tool I'm aware of does it right, so I doubt HeidiSQL will succeed where everyone else fails (no offense, Anse). By adding half cooked features you can't rely on we won't have a better tool.
The idea would be for HeidiSQL to keep track of all DDL statements (CREATE, DROP, ALTER and such) since connection start, separated per database, and have them displayed/exported on request - either as a SQL file or copy-pastable text in a query tab.
This would allow to easily replicate on a deployed server any modification that has been tested and found working on a test server first (which is more or less the way a lot of people develops web applications - playing first on a localhost copy of the app and porting things over to the "real" one once it seems safe and sound).
Doesn't it sound like a great plan to make a start at comparing field-types within tables? After that, the complete comparrison features will automatically follow
A pretty easy solution that would be handy would be an option to select objects (databases, tables, etc.) for comparison and heidi would make CREATE statements for these objects and send them to an external diff tool like TortoiseDiff or some other user-defined tool. This should be easy to do and would provide an easy way to compare structures.
Please login to leave a reply, or register at first.