I agree you . i don't like to use EF for many reasons and yes you have right
EF wrote for you everything and that is the part which is almost don't like it
When things go wrong, you are going to need to look deep into the code from EF wrote for you. So how fast can you read and undersatand the generated code so that you can identify what the issue is and how to fix it? and etc etc .. but sometimes it's interesting to create tabels or use Code first using C# Dapper Plus for instance doing great job about it .
I agree with CHill60 - I always use SSMS.
Data design is too important, it needs careful thinking about if it's going to be both performant and flexible. Far, far too easy to "let the machine do it" and it makes unwanted assumptions about your data that lead to problems later.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
Depends on whether it is new development or "maintenance".
With new development, the requirements and feasibility (e.g. skills; interfacing) dictate the technology.
With maintenance, you stick with what's there.
(it's never as simple as picking items from a menu).
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
Well... I'm lazy, so - probably - i'd prefer to automate it via c# code. I'd create a programme wich will acts as you described in 2-3 and 5-8. I'd save final result in a text file (with .sql extension) and use it in SSMS window.