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 12345»»»

Checking Up on Developers Expand / Collapse
Author
Message
Posted Thursday, May 7, 2009 9:09 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 6:20 PM
Points: 33,078, Visits: 15,192
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
Posted Thursday, May 7, 2009 9:51 PM
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 @ 12:39 PM
Points: 3,122, Visits: 11,405
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
Posted Thursday, May 7, 2009 10:13 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Thursday, June 5, 2014 10:54 AM
Points: 9,902, Visits: 9,480
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
Posted Thursday, May 7, 2009 10:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, July 24, 2014 7:55 PM
Points: 6,582, Visits: 8,860
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
Posted Friday, May 8, 2009 12:47 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:43 AM
Points: 1,434, Visits: 721
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
Posted Friday, May 8, 2009 12:51 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 3:45 AM
Points: 166, Visits: 1,052
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
Posted Friday, May 8, 2009 1:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued 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
Posted Friday, May 8, 2009 1:38 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:57 AM
Points: 1,049, Visits: 3,002
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
Posted Friday, May 8, 2009 1:51 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 2:19 AM
Points: 1,148, Visits: 1,071
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
Posted Friday, May 8, 2009 1:55 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 577, Visits: 2,503
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 »

Add to briefcase 12345»»»

Permissions Expand / Collapse