November 2, 2001 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/wp_gui.asp
December 3, 2001 at 5:39 am
The problem with this article is that it's not completly true.
I work in almost the same environment as the one in the article: a development server (20 metters away from my desk) a testing server (in the same building but very far) and a production server (2000 km or more away from me).
Do I use the GUI?
Yes. I use the GUI on the development server it's a pain in the ass to use scripting when you are not 100% sure that you are doing exactly the right thing.
Do I use the GUI for the other servers?
NO. What I am doing is initialy rely almost completly on the GUI and after that I am generating the scripts needed (from the GUI) adapt them a little bit and launch them on the other servers.
This way I am not writing tones of code that I will use only 3 times in my life but I can handle all the problems in the article while having the generated script saved in VSS (for example).
December 3, 2001 at 5:58 am
Steve, not sure Im totally convinced either. Wouldn't combining EM with a compare tool like the one Red-Gate makes give you the best of both worlds?
I see a lot of people totally skip EM in favor of a command line, when EM would be clearly faster - take attaching a db as an example, faster to browse and pick the file than to get the whole path correct...usually anyway!
Interesting article still!
Andy
December 3, 2001 at 8:32 am
I thoroughly agree with this as a worst practice. I am always advising people to use the EM as you suggest, make your changes and save the script. Scripting allows me more control over changes.
Also, the GUI sometimes does drastic things to make simple changes. I have had the GUI completely drop and readd a table when I did not think it was necessary. This causes all dependencies to go away and makes the sp_depends system procedure useless when I try to use it later.
Edited by - Jrein on 12/03/2001 08:33:04 AM
December 3, 2001 at 10:05 am
I will admit that the GUI is easier to use, but that is often the problem. People mistake ease for right or the best way.
If you use the scripts from the GUI, thenI hope you check them before you run them again. In this way you are not "depending" on the GUI, you are using it to your advantage. If you use scripts, you must also determine the proper order in which to run them. You don't want to implement a FK before creating the table, so you are not depending on the GUI in this way either.
The point was that so many people use the GUI for all changes, to development and production. This is where they get into trouble. How many times do people post in these forums somehow assuming the EM does some "magic" when it alters a table instead of reading the script and finding out that it really drops the table and recreates it.
I do use the GUI, but as edo_2000 uses it, usually when I don't remember the exat syntax. However, for tables and other objects, I want the documentation and so I script them and their changes. In this way, I can add my comments, or change them if I am not sure. I think that by scripting you are more likely to stop and think rather than just doing something.
As far as RedGate's tool, I have to apologize to Simon and the crew at RedGate, I haven't tested it yet. However, rather than a GUI based tool like EM where I am not sure what I want, I'd rather have some more intellisense in QA where I can type "attach database from file" and have it start prefilling the path based on what I type, like the address bars in W2K or IE. I really dislike depending on these tools if I am not 100% sure what it is doing in the background. Too often the author had a different philosophy than I.
Thanks for the comments and keep them coming!
Steve Jones
December 3, 2001 at 4:21 pm
Cant believe you ain't tried it! I'm curious to hear your thoughts once you do. Intellisense in QA would definitely be a productivy enhancer. Both tools are useful, I believe that the trick is choosing the right tool for the right task for the right reason. To just use one or the other exclusively limits your options and your productivity.
Andy
December 3, 2001 at 5:01 pm
Thanks for the thought provoking article, I agree entirely with Andy; and Steve - you really should check out SQL Compare, it's a great product.
I think that a text based environment is fine for change control and production databases, but development has to be done in GUI.
As for GUI environments I use Access 2002 ADP's extensively - although it has a great many limitations, I believe it is far better than EM for working with large databases in a development environment.
I ALWAYS look at code through a GUI envrionment. I think you have to be a SQL guru to understand the complex relationships in a large query in a text only mode. Looking at it in a GUI environment is much easier to understand.
December 3, 2001 at 5:53 pm
I'll give it a try, but I'm not sure a GUI is necessary. As a design tool, I'd agree, but for making changes, I think I'll stick with my scripts.
Steve Jones
December 4, 2001 at 7:47 am
Agree with Steve completely. I have been functioning as a full time DBA (part time doing other tasks prior to this) for less than a year and I believe that because I purposed myself to stick with scripting rather than the "Good Ol' GUI" I am much farther along today in my knowledge and support skills with SQL Server than I would have been if I had stuck with GUI support and development.
Thanks Steve!
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 4, 2001 at 8:28 am
I am an extensive user of the GUI. If it can be done with the GUI then thats how I do it for the time savings are great. But to be fair, I also use Embarcadero Change Manager and DB Artisan. 2 tools I would not like to do without. Without these tools I would agree that the GUI is not the "Best Practice". Another thing we have done is locked developers out of the developement server as well as production. Since we did that mysterious things like droped tables and restores stopped happening. Now everything filters through me, I assure it is correct with our standards and life is great. I'm down to only 2 asprin a day, and my cursing has dropped below the 'sailor' level!
- Vega
December 4, 2001 at 8:55 am
Hi all
Good article Steve. I come from the Oracle world where a decent GUI was something i longed for over many years (for the record, Oracle enterprise manager and their so called gui dba tools are totally pathetic). Why? well, i work as a development dba, i dont have time to bugger around with complex syntax, i want to select multiple object at once, i want to scroll around and pick options, i want to click a button for script generation, i want gui representations of growth and statitics, of column data distribution etc etc...
If your smart about it, especially between dev -> qa -> prod, you can get sqlserver gui and scripting to do everything you ask for. The DBA still requires thorough knowledge of "what" they are doing, and "why" its being done. Hand writing scripts, debugging the so and so's and missing options because you didnt read all of the ba-zillion possible options correctly for the objects creation is all fine, but when I have eight 280 table databases on the go with 20 contractors, i need all the help I can get to maximise my productivity, be it 3rd party or MS's products. GUI aint evil, its great intuitive technology.
{note: always check via profiler to see what the GUI is doing, at times I cringe with supprise to find a simple change is dropping and moving data around that 1 simple statement can achieve. this is hard to argue for but its a catch 22)
The real trick is RECOVERY and BACKUPS. No having a complete and thorough understanding here without any GUI is critical. Good luck to any DBA that relies on GIU for this.
Cheers
Chris
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
December 4, 2001 at 10:26 am
Thanks for ripping up EM, and telling us at the end what really is a best practice. Shouldn't you mention scripting changes from EM in the begining? Typing CREATE TABLE with 20 columns and couple of indexes dozens of times is not my idea of fun or efficient work. To put it another way, do you know the syntax for sp_add_jobschedule without Books Online? And what is faster to do?
December 4, 2001 at 10:54 am
This isn't a best practice article. Instead, it says the "worst practice" is depending on the GUI, not using the GUI. I appreciate all the comments and most are valid. Yes, the GUI does make things easier, but using it to develop scripts is different than depending on the GUI for your changes. The point of the article was to point out that too many people depend on the GUI for everything, including the managing of change.
The end of the article was to provide a little balance and note that EM is not always a BAD choice.
Thanks again for the comments, they are interesting and give me a different perspective.
Steve Jones
December 4, 2001 at 11:08 am
I agree with Steve 100%. I would add one thing. Although 'these GUIs are one of the reasons that so many people find it easy to administer Microsoft products', the GUIs also allow people to administer Microsoft products POORLY! I find more and more that people think that because they can navigate a GUI, they can administer, design and develop a database. As the tools hide the mechanics of the processes, less people understand what's going on under the hood.
Some of the people who disagreed with Steve indicated that using the syntax was more complex and time consuming, but I would say that in most cases IF YOU KNOW WHAT YOU'RE DOING, it's quicker to make changes and administer in query analyzer than EM. Going thru all those screens in EM drives me crazy.
I think that the rise of the GUI has clearly lead to a decrease in knowledge for many new DBA's and the erroneous conclusion by managers (many of whom can't can't spell DBA) that anyone can administer a database.
December 4, 2001 at 11:38 am
Its not always just a matter of knowing what you're doing. Often sure, but not always. I get paid to get stuff done. Done right, done fast. If QA can do it better, good enough. If EM works better, that is good too. In some cases I have have my own wizards for doing repetitive tasks - why not?
If it was up to me, everyone who believes QA is the best should have to use EM exclusively for two weeks and vice versa for EM proponents. And all you TSQL guys should have to spend two weeks using DMO!
Andy
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply