Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Career
»
Presentations and Speaking
»
Jacksonville Code Camp 2012
Jacksonville Code Camp 2012
Rate Topic
Display Mode
Topic Options
Author
Message
Brandie Tarvin
Brandie Tarvin
Posted Friday, September 21, 2012 6:18 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 10:25 AM
Points: 6,668,
Visits: 5,694
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, MCDBA, MCSA
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
Luis Cazares
Luis Cazares
Posted Friday, September 21, 2012 8:52 AM
SSC Eights!
Group: General Forum Members
Last Login: Yesterday @ 3:57 PM
Points: 960,
Visits: 1,923
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.
Please don't trust me, test the solutions I give you before using them.
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1362736
bitbucket-25253
bitbucket-25253
Posted Friday, September 21, 2012 11:59 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 7:33 AM
Points: 5,103,
Visits: 20,213
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
Grant Fritchey
Grant Fritchey
Posted Monday, September 24, 2012 5:26 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 10:36 AM
Points: 13,383,
Visits: 25,184
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
Brandie Tarvin
Brandie Tarvin
Posted Monday, September 24, 2012 5:54 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 10:25 AM
Points: 6,668,
Visits: 5,694
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, MCDBA, MCSA
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
Grant Fritchey
Grant Fritchey
Posted Monday, September 24, 2012 6:14 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 10:36 AM
Points: 13,383,
Visits: 25,184
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
Sean Pearce
Sean Pearce
Posted Monday, October 22, 2012 2:13 AM
Old Hand
Group: General Forum Members
Last Login: Today @ 2:27 AM
Points: 350,
Visits: 1,340
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.
http://thesqlguy.blogspot.com/
Post #1375298
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.