Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Jacksonville Code Camp 2012 Expand / Collapse
Author
Message
Posted Friday, September 21, 2012 6:18 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:34 AM
Points: 7,132, Visits: 6,293
My session got selected for October 6th's Jacksonville Code Camp, hosted by the Jacksonville Development Users Group. Yay, I get to speak in front of a bunch of developers.

Crap, I have to speak in front of a bunch of developers.

This feels different than speaking at a SQL Saturday... I'm hoping the fact that my session is on SQL Server Database Basics means I'll be able to survive the session feeling like I do have a clue. Here's my summary:


You've developed the greatest thing since sliced bread, but the Database Administration team won't let you hook it up to their database. From schema to security to space and performance issues, this is a high-level overview of what DBAs see as their most important challenges when integrating other people's code into their system. A fascinating look at how the other half works.


As I'm developing my content, I'd like to ask all you SQL developers out there, what items do you wish you knew back in the day before you started butting heads with the DBA team?



Brandie Tarvin, MCITP Database Administrator

Webpage: http://www.BrandieTarvin.net
LiveJournal Blog: http://brandietarvin.livejournal.com/
On LinkedIn!, Google+, and Twitter.

Freelance Writer: Shadowrun
Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
Post #1362597
Posted Friday, September 21, 2012 8:52 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 1:23 PM
Points: 3,365, Visits: 7,283
It would have been great to understand the difference between row-by-row programming and set based programming (or procedural language and declarative language). It would be important to notice when is it better to use one or the other.

I hope I can go to Jacksonville if I'm still in Florida for that day.



Luis C.
I am a great believer in luck, and I find the harder I work the more I have of it. Stephen Leacock

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1362736
Posted Friday, September 21, 2012 11:59 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:28 AM
Points: 5,573, Visits: 24,808
Luis Cazares (9/21/2012)
It would have been great to understand the difference between row-by-row programming and set based programming (or procedural language and declarative language). It would be important to notice when is it better to use one or the other.


+1

My first experience used a cursor and hence row-by-row processing and that required hours, yes hours to complete. Once I learned set based techniques the same job was reduced to mere minutes.


If everything seems to be going well, you have obviously overlooked something.

Ron

Please help us, help you -before posting a question please read

Before posting a performance problem please read
Post #1362886
Posted Monday, September 24, 2012 5:26 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 12:27 PM
Points: 15,541, Visits: 27,919
Yep, I agree set-based processing is the biggest.

After that, some talk about why modifying databases is such a pain. Why relational storage is actually good for performance, not just a pain in the bottom. Why id/value databases can't answer all questions. Why object databases are bad for reporting.

Those are the ones that immediately come to mind.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1363425
Posted Monday, September 24, 2012 5:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:34 AM
Points: 7,132, Visits: 6,293
I've never used object databases. Can you point me to some reference material? EDIT: Reference material regarding your reporting comment, that is.

Brandie Tarvin, MCITP Database Administrator

Webpage: http://www.BrandieTarvin.net
LiveJournal Blog: http://brandietarvin.livejournal.com/
On LinkedIn!, Google+, and Twitter.

Freelance Writer: Shadowrun
Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
Post #1363434
Posted Monday, September 24, 2012 6:14 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 12:27 PM
Points: 15,541, Visits: 27,919
Brandie Tarvin (9/24/2012)
I've never used object databases. Can you point me to some reference material? EDIT: Reference material regarding your reporting comment, that is.


Ah, I meant databases generated by ORM tools. They create an objects as if they were relational storage. It makes coding the app easier, but reporting cuts across the objects in ways that requires you to do gigantic joins. I don't have specific documentation on it to provide you. Sorry. I need to go spend a few weeks at my old job to see what horrors they've created now and write up a few blog posts on it.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1363442
Posted Monday, October 22, 2012 2:13 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 8:33 AM
Points: 832, Visits: 2,683
I'm currently living in an ORM DBA nightmare. Pulling data for reporting requires an inordinate amount of complex code. Maintenance is hell. I really wish the developers had consulted a database professional when the project was in the design phase. Now, 6 years later, we are stuck with a monster.

Joe said it best in his book "Joe Celko's SQL Programming Style"
3.15 Do Not Use Object-Oriented Design for an RDBMS
Rationale:
Many years ago, the INCITS H2 Database Standards Committee (née
ANSI X3H2 Database Standards Committee) had a meeting in Rapid
City, South Dakota. We had Mount Rushmore and Bjarne Stroustrup as
special attractions. Mr. Stroustrup did his slide show about Bell Labs
inventing C++ and OO programming for us, and we got to ask
questions.
One of the questions was how we should put OO stuff into SQL. His
answer was that Bell Labs, with all its talent, had tried four different
approaches to this problem and came to the conclusion that you should
not do it. OO was great for programming but deadly for data.




The SQL Guy @ blogspot

@SeanPearceSQL

About Me
Post #1375298
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse