#Tableplus m1 how to

But not just that, you could also forward engineer this ER diagram of yours to get SQL that you could apply to a live instance, or vice versa - to create an ER diagram of an existing DB instance. You could design your entire schema as an ER diagram, thus being able to play around with how everything could be laid out extremely easily and also get a visual 'feel' for that it'd end up being like and how your queries could work. To expand upon the argument of leaning into GUI tools for stuff like this, or to offer my own opinions, i really liked the functionality of MySQL Workbench. Don't feel pressured, do what works for you. These are not fundamentally complex or magic (there will be times you wonder at the stupidity of the query plan), there are books on this and lots of articles out there.įor small dbs, no problem, but as they grow not understanding the optimiser will kill you.Īnyway, my experience.

#Tableplus m1 how to

You need to understand what the query optimiser does and how to give it the info it needs (indexes, clustered indexes, stats, whatever), which the wizard will not help you understand. If you know what you are doing you 99% don't need it (I've got a couple of useful tips off it, ever, that's all). The index wizard is likewise de-skilling. There's a small hump to get over to learn to write SQL queries, it's worth getting over (IMO) (there are times when I'd like to take a large existing multi-way join and see a pic of it though). Visual query builders are a deskilling device. If you're using SQL on small DBs you can probably get away with what you do, for large DBs that won't fly. This is just IMO and it depends on your needs, but these fit mine.