Jacksonville Code Camp 2012
-
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?
-
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 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.
-
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 RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
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 (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 RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
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.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply