August 14, 2018 at 2:41 pm
Steve Jones - SSC Editor - Tuesday, August 14, 2018 9:20 AMroger.plowman - Tuesday, August 14, 2018 6:55 AMI've been an application developer for over 40 years and I'm a rabid supporter of the "database design is FIRST" philosophy.But I take a bit of exception to Steve's "learn to script" emphasis, downplaying GUIs. The primary reason I say this is the existence of proper ERD design tools. Things like Rational Rose and ModelRight are first and foremost visual design tools to let you design a database the same way a building is designed--using a CAD tool approach.
...
Having said that, for God's sake, get some power tools! There's no sense trying to build the Empire State Building of databases using hand-saws and hammers, right?I'd still argue that scripting really matters. You need to process to be repeatable and reliable. Using a GUI to generate the code, fine, though you'll want to ensure you review the code, at least initially. There may be defaults or choices the scripting engine chooses that you don't want in your final script, especially as the platform can evolve quicker than the tools. You also want to be able to chain these scripts to run quickly, not based on a user pressing the right button in a GUI.
Whether RationalRose or SQL Compare, I'd argue that I want to drive these tools from a CLI that allows the tool to work, but ensures I get a repeatable method of deploying the code. I always want a script, if for no other reason than logging.
I agree that tools are useful and almost necessary once you work at scale or at any pace. They truly to help you visualize your design and work well to ensure you don't forget something. Use tools, Redgate if you find them helpful, or someone elses', but use tools.
Just be sure you can script and you know how to reliably deploy the code they produce.
ModelRight, for instance, does create a script. One I run from SSMS in fact. 🙂 However, ALL design work needs to begin in the ERD designer, then the necessary code taken from it as a script.
That way, the documentation is the FIRST step, just like altering a blueprint. Can't get any more repeatable than that...
August 15, 2018 at 2:34 am
I absolutely agree but I don't feel that should be mutually exclusive with GUI tools. I think one of the reasons DB professionals tend tend to want to script everything while App developers tendtend to reach for a GUI is that App development GUIs have, historically, been pretty good in this regard while DB GUIs have been pretty woeful.
I think you're confusing a few things. First, in VS, we do the development. The output of that might be some code in a script, which goes into a VCS. However, we don't deploy that in the same way. If it's C$ or SSIS code, we're copying over the package. If it's R/Python scripts, we are copying files. THOSE are the items that need to be scripted to be deployed.
The equivalent to the DB world in SSMS would be, do you want to trust the developer to drag the same control and set the same options again for the test server? Do you want them to do that again for the prod server? No way. You need to be sure what happened in dev is what happens in prod. That's where you need a CLI method of making your changes. The CLI can be running the same script/code in your GUI tool, but it must be repeatable. For devs, because you work in a stateless manner that passes forward the results of your work, not the work.
In SSMS, would you want to right click the server, change the query timeout or maxdop, and then click OK. Then do that again in prod? Many of us do, but that's not repeatable. We could make mistakes. For what Roger mentioned, the equivalent would be making the change in RationalRose, deploying to prod. Then connecting to prod, making the same change again in teh diagram, and deploying it. That's not repeatable.
August 15, 2018 at 12:17 pm
I have experienced many application rewrites and replatforming over my career. Very few down to obsolescence, most down to the app being replaced having descended into a big ball of mud. Sadly the rewrites always resulted in Big Ball of Mud n+1.
This is because it is culture, processes and lack of respect for discipline that provide the things the cause the descent into the mire.
Fred P Brooks tells us that no technology will yield an order of magnitude improvement in productivity. See "There ain' no silver bullet". He's still right 44 years later.
Joel Spolsky has a popular blog post on things you absolutely must not do and that is rewrite.
I had a Twitter conversation with Ron Jefferies, the founder of XP programming and he suggested that continually improving what you have would be preferable.
Misuse of ORMs fits in with those things that are driven by culture
August 15, 2018 at 1:09 pm
Oh, how true this is. 🙁
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
August 15, 2018 at 1:49 pm
I think you're confusing a few things...
Weird. Don't know who posted this but it seems to have replaced my post, which it quotes. And it appears to have been posted by me, which it wasn't. Spooky!
Anyway, I don't think I have misunderstood, rather I believe you've missed my point (probably down to my own clumsiness, I often seem to give the wrong impression). When I make a change in VS it's repeatable automatically into test, then UAT, then live, without any human interaction. That's fundamental to the development process, especially if I'm working in a CI manner. The same is not true when making changes in SSMS and If I want that automatic repeatability I'm forced to turn to scripting. That's the weakness in SSMS that I'm lamenting.
I get that with VS I'm typically pushing out the resultant state rather than the difference but 1. not always, I've worked with VC systems that are Diff based rather than State based (CVS is the one that most readily springs to mind) and 2. again, I don't care. I just want a tool that works and I don't care about the mechanism.
So to answer the question "do you want to trust the developer to drag the same control and set the same options again for the test server?", no. I absolutely don't want that. I want it to be automatically repeatable in the same way as changes I make in VS are.
If I'm reading you correctly we're actually saying the exact same thing - just from opposite directions: we want automatic repeatability and SSMS doesn't provide it.
Personally, I'm increasingly finding myself using code first but not because I agree with the approach (I actually much prefer DB First because I think a database designed informed by the object model is far more likely to be flawed than an object model informed by the database design) but rather because the tooling provides me better repeatability. In truth, I suspect I'm mentally still doing DB first, I'm just using Code First tools to do it.:hehe:
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply