March 27, 2015 at 3:02 pm
So far as SQL Server database work is concerned, I'm strictly an SSMS man. Used to use Query Analyser and Enterprise manager. I've never touched SSDT. This is despite the fact that I'm a general software developer, not just database specialist, and I've used VS as least as much as I've used SSMS and EM put together.
I have always worked more in some other language than in SQL, sometimes in the fifth worst language ever invented (C++) sometimes in one nowhere near that bad (JavaScript), but not in the fourth worst language ever invented (Java), the 3rd worst (PL1), the second worst (BASIC), or the worst (VB).
I introduced the use of SourceSafe for source control for SQL Server database work at two different companies, and found that putting database work into the same source control system as procedural, OO, and other stuff actually convinced developers that it was just as important and needed just as much care as those other things, as well as fitting in pretty well (although some more automation might have been nice) with EM and SSMS. I would be extremely surprised if modern VS source control mechanisms aren't perfectly satisfactory for use with SSMS.
I haven't done any serious work at all with report generation, data warehousing, or BI so I don't know whether workig with those bolt-ons would find SSDT useful (well, I've done a bit of report generation done by hand in T-SQL, JScript, and HTML because the people who had spent ages of time and oodles of dosh on trying to do it with "the proper tools" had achieved exactly nothing, but that obviously didn't use the "prop'er tools" that might fit better with SSDT).
Tom
March 27, 2015 at 3:36 pm
Doesn't everyone use both? I use SSMS for data discovery, scripting tests, and checks and monitoring. I like to write and refine queries in SSMS first, then copy the code over to VS. I use SSRS, SSIS, or SSAS nearly everyday, but the graphical baggage sometimes slows me down. I really like having SQL code at hand in a simple text file so I can review it quickly.
March 27, 2015 at 4:29 pm
My own answer is that I tend to just use SSMS because it does what I need. I'll use VS for .NET stuff, but otherwise SSMS only. I've rarely opened SSDT, though I'll probably experiment more with it, just to understand what works well.
March 28, 2015 at 5:24 am
TomThomson (3/27/2015)
trboyden (3/27/2015)
Pretty much live in SSMS and code T-SQL in my sleep. However if writing a .NET app, I'd be curious why the discussion is SSDT versus using the Entity Framework which seems to be the way to go for data persistence strategies in the current ORM world? Personally, I prefer the Grails Framework for doing ORM-based applications, but I digress.I suspect that anyone who understands what the relatinal model is and has read the third paragraph of the wikipedia page on ORM would do almost anything to avoid going anywhere near an ORM-based approach. That's perhaps why the discussion doesn't go there.
ORM is just a framework assisted version of the Normalization process good SQL developers go through when designing their databases. It's targeted more at application developers (same as SSDT) who aren't expected to know the intricacies of database design and performance management. Good ORM-based frameworks like Grails, hide the ORM activity in behind the scenes automation so the developer can concentrate on their application design. Such frameworks also let the developer switch between data persistence targets (MS SQL, Oracle DB, XML, flat-files) interchangeably and application is unaware of the under-the-hood differences. My reading reference, for anyone interested, is Getting Started with Grails, by Scott Davis (http://www.infoq.com/minibooks/grails-getting-started). It's a quick tutorial that gets you into the meat of Grails and ORM topics quickly with an entertaining application scenario.
These days I do mostly back room SQL work, supporting an ERP system, so I don't do much ORM or application development work anymore.
March 28, 2015 at 9:48 pm
trboyden (3/28/2015)
TomThomson (3/27/2015)
trboyden (3/27/2015)
Pretty much live in SSMS and code T-SQL in my sleep. However if writing a .NET app, I'd be curious why the discussion is SSDT versus using the Entity Framework which seems to be the way to go for data persistence strategies in the current ORM world? Personally, I prefer the Grails Framework for doing ORM-based applications, but I digress.I suspect that anyone who understands what the relatinal model is and has read the third paragraph of the wikipedia page on ORM would do almost anything to avoid going anywhere near an ORM-based approach. That's perhaps why the discussion doesn't go there.
ORM is just a framework assisted version of the Normalization process good SQL developers go through when designing their databases. It's targeted more at application developers (same as SSDT) who aren't expected to know the intricacies of database design and performance management. Good ORM-based frameworks like Grails, hide the ORM activity in behind the scenes automation so the developer can concentrate on their application design. Such frameworks also let the developer switch between data persistence targets (MS SQL, Oracle DB, XML, flat-files) interchangeably and application is unaware of the under-the-hood differences. My reading reference, for anyone interested, is Getting Started with Grails, by Scott Davis (http://www.infoq.com/minibooks/grails-getting-started). It's a quick tutorial that gets you into the meat of Grails and ORM topics quickly with an entertaining application scenario.
These days I do mostly back room SQL work, supporting an ERP system, so I don't do much ORM or application development work anymore.
Ye gods and little fishes!!
Every ORM I've come across is utterly contrary to normalisation. The activity is carefully hidden behind the scenes to conceal the fact that it's destroying performance and (less often) destroying integrity.
I mustn't say more, I'd probably be unacceptably offensive if I did.
Tom
March 29, 2015 at 8:30 am
Tom I tend to agree with you about ORMs but have a different opinion on languages both from a technical and preference perspective.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 30, 2015 at 7:01 am
I use SSMS. Haven't used anything else.
March 30, 2015 at 8:42 am
For development, SSMS with some useful add-ins (SSMSBoost and SQL Search).
SSDT for Source Control, Database Schema and Data Compare, Snapshots and build install/upgrade scripts.
Nuno Silva
March 30, 2015 at 3:20 pm
I'm right there with you, on the same path, working to get there.
March 30, 2015 at 3:21 pm
SSMS for admin tasks, SSDT for development. The more I use SSDT the more I like it.
March 31, 2015 at 9:02 am
Mostly SSMS, but I am starting to use SSDT more, and would like to learn more SSDT best practices to make the most of it. Seems quite complex to me.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
April 5, 2015 at 1:42 pm
I've used SSMS mostly and prefer it. I've not really used SSDT all that much. Can you do things like create SQL Jobs in SSDT?
Rod
April 5, 2015 at 7:52 pm
I'm all SSMS as a SQL Developer. I'm all SSDS when everything else.
April 5, 2015 at 8:05 pm
Doctor Who 2 (4/5/2015) Can you do things like create SQL Jobs in SSDT?
The last time I used SSDT extensively, it wasn't possible. That was almost three years ago. Maybe that has changed.
Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv
April 6, 2015 at 2:58 am
Doctor Who 2 (4/5/2015)
I've used SSMS mostly and prefer it. I've not really used SSDT all that much. Can you do things like create SQL Jobs in SSDT?
Technically, I see no reason why you couldn't run sp_add_job from SSDT, but that's probably not what you had in mind.
There seems to be no capability to include Agent jobs in database projects, but that makes sense, as they are not related to any user database.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 15 posts - 61 through 75 (of 97 total)
You must be logged in to reply to this topic. Login to reply