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.