Worst Practices - Depending on the GUI
-
DMO Sucks!!!!!!!!!!!!1
Actually, I do agree with Andy somewhat. The best tool is the one to use. I do use EM in certain places that I can never remember the syntax. That's where I'd like to see Intellisense in QA. I also have lots of snippets as templates in QA because it allows me to do things quickly. If I could script everythign from EM, somethings I cannot easily script, I'd probably use it more, though still do most things in QA.
I do need to spend some time in DMO and get to use it and see what I think.
Steve Jones
-
Alright Andy - I'm reading your articles on DMO and am now thoroughly convicted to do SOME work that way.
Thanks for the laugh Steve!
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
-
-
Good deal David, I look forward to your comments.
As for you Steve - yeah, all two of us! DMO is most valuable to a VB developer, a good one will quickly understand the object model.
Andy
-
All I can say is... "dont make your life harder that it needs to be!"
Anyone who thinks coding t-sql, dmo, pouring over scripts manually is FUN and its necessary to be a "great dba" who knows everything about SS's in's and out's. People who try are suckers for hard work! 😉 Even things like, "do know how to schedule a job without the GUI" is a strange comment, of course i do, crank up help and 2 secs later you have it, why force yourself to remember such irrelevent factual information, id prefer to concentrate on SQL tuning and how to squeeze more performance out of my top 20 worst queries (all collected via GUI's btw because its a damn site easier).
Buy GUI's and learn to love em. They are not worst practice and never will be. You dont get employeed because you know how to write scripts by hand and take 3 days to do it. In the end you are answerable to the boss, and if you used a gui to build your merge replication in prod and you dont really know how it works, then you have a "what is a dba? and how did i get this job?" problem, not a problem with GUI's.
Good I love a good discussion!
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA" -
good comments, but I'd still say that a good dba will not depend on the gui. he might use it, but will not depend on it.
Steve Jones
-
IMHO Enterprise Manager as the only SQL Administration tool := Bad Practice
This is because you lack tracks to show what you did, except in the diagrammer. GUI's seldom leave tracks.
But, EM is great for noodling around in developer mode. I have had some of my best insights and "ah hah's!" looking at the code behind the EM's actions. It is easy enough to clip that SQL code out of the SQL window and paste it into Query Analyser, and this especially works well in learning mode.
The environment that I work in, is one that *all* production or pre-production jobs are scripted, almost everything is scripted. Why? Because you have an audit trail of the actions that you have performed against a server, (that is assuming that you capture the script outputs.....). We have used this technique for litigation support.
For example, imagine saying: "Why yes, Ms. Opposing Deposition Taking Attoney, as you can see here, the data was replicated from the server on this date and time to the CD which you have in your hand. And no, since the media was locked with the database and corresponding script outputs and logs, I can definitely state in my professional opinion that it is a true picture of the database at that point in time."
You get the point, I'm sure. I love GUI's to "see" complex concepts, but I'll always try to have that scripting and its output around for documentation.
-hal
-
-
The great thing about scripting is that you are creating documentation for your database.
I also find that a well laid out script is useful teaching aid for educating wannabe developers.
When I did the Microsoft Admin and Microsoft Design courses the MCST's went to great pains to tell us to avoid using EM. In fact they called in Enterprise Mangler.
I find that EM's scripting facility produces scripts that I have to alter anyway, so there is little time saving for me.
The EM Scripter doesn't seem to take into account DRI or let you specify the order in which you want objects created.
It is probably a hidden object, but when I've gone to the trouble to create rules and defaults and bound them to a user defined type I really would expect the EM Scripter to take into account these types and not generate loads of duff defaults and rules bound at column level.
Then we have Microsoft's fascination with fixing the unbroken. Where the hell is "Truncate Log On Check Point" in SQL2000 EM?
In short, I use EM for firing off jobs, quick back ups, building DTS packages (then saving to the OS), prototyping, but any shots fired in anger I do via scripts.
- That's funny.
I use EM everyday. I'm not trying to boot the tool, but it shouldn't, IMHO, be THE tool for scripting changes for your db. The biggest argument against EM is in MOVING changes from dev to production, not making them. If there a "record a macro" functionality.....maybe I'd feel differently, but trying to remembe exactly what 20 changes I made last week in EM is impossible. And I have a 1-2 week developement to release cycle? What if you have a 2 month cycle?
Steve Jones
-
Steve - you gotta try SQL Compare - it'll change your life!
Andy
-
I agree with Andy, SQL Compare and its data comparison tools are excellent and I highly recommend them. EE does produce some dodgy script, dont get me wrong, it works, but sheesh, talking about doing it the hard way!... so long as all databases are identical, taking a EE script from one db to the other works a treat. I always full backup (because they are small db's) before scripts are applied.
Cheers
Chris
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA" -
I need to give it a try, but with my version control system and only a few dbs, I don't have any issues. Also the short release cycle (< 4 weeks over 99% of the time), the dbs between dev -> qa -> prod never really get out of synch.
Steve Jones
That's funny.Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply