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.
I guess I'm too lazy to write the program to do it
Having written such a program in the 90's for VB6, reworked for VB.net then for c# and now producing such things as WPF razor page templates and the CRUD stored procs I can relate to that. Except I start from the other end, create the tables in SSMS and then use ClassBuilder to do the bulk of the CRUD code.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
Having been a developer for over 20 years, and a SQL DBA and Administrator since 6.5. My Preference is to design the database using Management Studio. I do it this way
#1. Design the raw tables include the fields for the Foreign keys BUT do not link them yet
#2. Design your Clustered indexes I will name them IDX_tablename
#3. Be lazy and use the Database Diagrams tool to define your Foreign Keys
My reason for doing this if the DB is designed correctly your app will be far more stable. If you design your foreign keys first it becomes your clustered indexes and normally you will cluster on a name or account number and not the ID.