Checking Up on Developers

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Checking Up on Developers

98 posts, Page 1 of 10

1 2 3 4 5 »»»

Checking Up on Developers

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Thursday, May 07, 2009 9:09 PM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 11:20 AM
Points: 31,437, Visits: 13,752

Comments posted to this topic are about the item Checking Up on Developers

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #712574

Michael Valentine Jones

Posted Thursday, May 07, 2009 9:51 PM

SSCrazy

Group: General Forum Members
Last Login: Yesterday @ 10:43 AM
Points: 2,945, Visits: 10,517

The most common and worst mistake is failing to develop a normalized data model that fits the real world data.

Most developers seem to just throw tables together with little thought about how it actually models the real world data. Once a bad table "design" is in place, the application is doomed to an endless series of hacks to work around the design problems.

You can fix bad indexes and poorly written stored procedures, but a bad table design is with you forever.

Post #712591

RBarryYoung

Posted Thursday, May 07, 2009 10:13 PM

SSCrazy Eights

Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855, Visits: 9,374

Well SQL Injection is the biggie. Wish I had a buck every time one of my customers found out that their vendor was exposing them to SQL Injection attacks.

-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc. "Performance is our middle name."

Post #712601

WayneS

Posted Thursday, May 07, 2009 10:23 PM

SSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:12 AM
Points: 6,370, Visits: 8,235

Well, I'm on a new job, and am investigating performance problems. The first thing I'm looking at is everything that is causing deadlocks.

Every time, the root procedure is performing selects against multiple tables where the only indexes are on the PK, and a rowguid for replication. That's it. There queries are performing table/CI scans constantly. Adding a few indexes has helped tremendously with the stability of the server and their application.

Wayne
Microsoft Certified Master: SQL Server 2008

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links: For better assistance in answering your questions, How to ask a question, Performance Problems, Common date/time routines,
CROSS-TABS and PIVOT tables Part 1 & Part 2, Using APPLY Part 1 & Part 2, Splitting Delimited Strings

Post #712609

SQLPhil

Posted Friday, May 08, 2009 12:47 AM

Ten Centuries

Group: General Forum Members
Last Login: 2 days ago @ 9:48 AM
Points: 1,413, Visits: 660

Security considerations. Time after time I get databases come to me with instructions on how to deliver the various database objects, but no consideration on how users are actually going to be accessing them through the application. The worst offenders are the third party vendors where it just seems the norm to give the database user dbo privileges over the database.

Why - for the love of God - why dbo???? I'll just build another brick wall to knock my head against then!

Post #712657

AndrewJacksonZA

Posted Friday, May 08, 2009 12:51 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 07, 2013 5:52 AM
Points: 165, Visits: 1,022

I'm a programmer/developer at a small software development house (1 programmer, 1 manager, 2 network support guys) and I enjoy learning about how to do things properly, whether it be database or application related. Thanks for this topic, I'll be following it closely!

Post #712658

lloyd-236007

Posted Friday, May 08, 2009 1:23 AM

Valued Member

Group: General Forum Members
Last Login: Tuesday, October 18, 2011 5:53 AM
Points: 73, Visits: 21

. some of the fields in the table are of size greater than 8 kb and most times it cause page splits which causes slow performance.
. Normalizing a table without considering the implications such as too many joins while pulling out the data designers need to understand the benefits of denormalization as well.
. choosing non clustered indexes based on good selectivity instead of random fields
. Lack of understanding query plans and index seeks over table scans

Post #712672

majorbloodnock

Posted Friday, May 08, 2009 1:38 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 9:39 AM
Points: 1,043, Visits: 2,944

Personally, I think the most common mistake made by developers is also the most common made by DBAs; being blinkered.

The app and the database are two separate tools that, when used in conjunction, provide a solution to a business problem. However, whilst they are separate tools, there's a large overlap in functionality - some actions you may want to perform could be done by either app or database, albeit not necessarily with equal efficiency. I've seen many developers who'll only think about offloading functionality to the database when they physically cannot perform it in the app. I've seen many DBAs and DB developers who want to do pretty much everything in the database and only see the app as a bit of prettification for the users to look at. Both approaches have ended up with hugely inefficient solutions. Just because you can do something in a particular place doesn't mean you should.

The most effective solutions I've seen have been put together by people who understand the strengths and weaknesses both of their programming environment and database platform, and have distributed the work across both areas according to those strengths. It requires a particular attitude of openmindedness, and for all too many developers and DBAs that means a rather uncomfortable cultural change.

OK, I'll get off my hobby horse now.

Semper in excretia, sumus solum profundum variat

Post #712678

Michael Lysons

Posted Friday, May 08, 2009 1:51 AM

Ten Centuries

Group: General Forum Members
Last Login: Friday, May 17, 2013 1:59 AM
Points: 1,126, Visits: 924

Good grief, sweeping generalisation about developers there, Steve. Seems to me that if a developer is implementing incorrect indexes etc, then it's actually the DBAs fault for letting them do it. DBAs, eh - tut!

Post #712688

Phil Factor

Posted Friday, May 08, 2009 1:55 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Sunday, May 19, 2013 4:00 AM
Points: 533, Visits: 2,285

I'll repeat this one until I turn blue. It is a terrible mistake to develop an application with an empty database, or one with just a little 'sample data' in it. Develop your database with the maximum amount of data in it that you can predict is going to be in the production database: Then, your failure to provide the correct indexes will become flamingly obvious. If you've made a design error, it will hit you smack in the eye. All right. I'll admit that SQL Data Generator is very close to my heart, but the reason is that this, or a tool like it that generates correctly formatted and convincing data, will become your best ally when you are developing.

Other crimes
Allowing direct table-access to applications (madness because of security issues)
Denormalisation (you'll live to regret it when the application expands)

Best wishes,

Phil Factor
Simple Talk

Post #712691

« Prev Topic | Next Topic »

98 posts, Page 1 of 10

1 2 3 4 5 »»»

Permissions