loooooooooooooong Introduction! There are effectively 2 people I am talking to with this talk. Non-DB Developers and DB-Developers.

DB Dev VS. Other Dev C# developers are not the same as a Junior DB developers. C# developers understand complex coding patterns and methodologies and are accomplished in their fields. How is it then that sometimes we cannot create a platform for them to dev in our space?

What causes the most live problems? Speed  Either querying a table that is too big/not using indexes. Data value – Dirty reads/bad transaction handling – non-repeatable reads. OR we are valuing data too highly and locking a valuable resource.

The biggest difference: dataInertia once it is generally understood that there are more things to realise than just accuracy (and that accuracy is no longer binary) then you are making headway.

horrible question… If you design your environments with multiple professional users in mind then there will be safe areas for people to just code without fear.

solution? For every database you have you should be able to build a profile of what is and is not important – which tables are big – which tables are contentious – Lets build a list.

comments (inline or otherwise): Where does description of behaviour exist? Major difference to (C#)compiled code is that DBA’s will be able to and will try to troubleshoot – good documentation will allow them to do this quicker.

Database environment – Audit112: Comments: Add comments in body of all objects. Database environment – Reporting: Comments: Add comments to your changelog.

Query guidelines: Join/where clause on columns with indexes only Query guidelines: Join/where clause on columns with indexes only. Return less than 10000 rows. (x) tables can be dirty reads. Your data could be super transient and you require a tab lock when querying?

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest.

Insert/update heavyVS. readheavy or readonly environments. Here you can define different behaviours: For read heavy environments the rule could be  Add indexes for days. For insert heavy environments the rule could be  not allowed indexes but make your keys properly sequential(ever increasing) if you have both it may be time to chat to your architect about separating concerns 

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig)

Dependencies environmentfunnies For each DB you can point out the pot holes or hidden items, Database triggers, table triggers, Replication to or from.

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Funnies: Replication SSB There are DB Triggers for DDL Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig) Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed]

Linked Servers (Y/N) Other options? Most Application developers will just query twice but make a rule about best practices.

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig) Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there.

Temp DB When/how should I use temp objects? More or less… Depending on the environment you are in, people who are not in the know will either horribly overuse TempDB  Dumping tables there willy-nilly because they have been told that it is quicker. The other option is guys never use it because once they used a table variable on a critical system and it spilled to disk and now they are scared!!!

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. TempDB: Not setup for ‘Active’ use (use sparingly) Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig) Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there. TempDB: Actively use temp DB for any transform. It is huge and on super fast storage

SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ANSI_WARNINGS ON SET ARITHABORT ON SET CONCAT_NULL_YIELDS_NULL ON SET NUMERIC_ROUNDABORT OFF SET NOCOUNT ON Just give everyone the same starting point. If you deviate from this it will be on your own head…

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. TempDB: Not setup for ‘Active’ use (use sparingly) Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig) Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there. TempDB: Actively use temp DB for any transform. It is huge and on super fast storage Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ARITHABORT ON

sizes: Variable tableVariable temptable when to add index? something like: Variables use at will, table variables up till 10 - 100. temp tables 100 – 1000, table variables with index 1000 - 1 GB.

Database environment – Audit112: … Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. TempDB: Not setup for ‘Active’ use (use sparingly) Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON Suggested Size: @Table = 10 to 1000 (ensure no spill) No temp tables Database environment – Reporting: … Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there. TempDB: Actively use temp DB for any transform. It is huge and on super fast storage Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ARITHABORT ON Suggested Size: No table variables Temp tables 10 – 100000 Temp tables(with indexes) > 100000

error handling 2 options only... Most times not handling SQL errors is the easiest and most accurate way of failing. Alternately a try catch block - proc with rethrow logic.

Database environment – Audit112: … Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. TempDB: Not setup for ‘Active’ use (use sparingly) Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON Suggested Size: @Table = 10 to 1000 (ensure no spill) No temp tables Error handling: Just don’t – let the error bubble up organically. Database environment – Reporting: … Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there. TempDB: Actively use temp DB for any transform. It is huge and on super fast storage Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ARITHABORT ON Suggested Size: No table variables Temp tables 10 – 100000 Temp tables(with indexes) > 100000 Error Handling: Any Updates or inserts use both Try Catch and sp_raiseLastError.

ServiceBroker, homegrownframework? Acceptable execution times? Try and give healthy guidelines for building anything in an established framework.

Database environment – Audit112: … Error handling: Just don’t – let the error bubble up organically. General: No unnecessary load on system from 28th to 31st of Month, Month End work takes priority! Add to table tb_process2Kill if your process is not critical. Database environment – Reporting: … Error Handling: Any Updates or inserts use both Try Catch and sp_raiseLastError. SSB Framework(ABC) in effect. All Procs must execute in <2 seconds SSB Procs are sp_procs_ABC_*

ControllingConcurrency If Data accuracy is in question. There is no shame in making no-go areas. ”This queue based system is off limits for non DB Devs…”

Database environment – Audit112: Comments: Add comments in body of all objects. Query Guidelines: Join and where only on Indexes Only return 10000 to client and 100000 for internal. Dirty reads allowed  *_Static and *_log. [Insert Heavy] environment: Do not create indexes! Funnies: Replication SSB There are DB Triggers for DDL Linked Servers – Do NOT use ever. TempDB: Not setup for ‘Active’ use (use sparingly) Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON Suggested Size: @Table = 10 to 1000 (ensure no spill) No temp tables Error handling: Just don’t – let the error bubble up organically. General: No unnecessary load on system from 28th to 31st of Month, Month End work takes priority! Add to table tb_process2Kill if your process is not critical.

Database environment – Reporting: Comments: Add comments to your changelog. Query Guidelines: Joins only 3 deep per statement. (NOLOCK) all queries. Only query data from yesterday – Data at rest. [Query Heavy] environment: Create any indexes you need(Join and where) Update indexes (<0.5gig) Funnies: Stand Alone DB – no Active Users Caching Job runs once a day [queries will be killed] Linked Servers – Use any that are already there. TempDB: Actively use temp DB for any transform. It is huge and on super fast storage Def. env. variables: SET QUOTED_IDENTIFIER ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ARITHABORT ON Suggested Size: No table variables Temp tables 10 – 100000 Temp tables(with indexes) > 100000 Error Handling: Any Updates or inserts use both Try Catch and sp_raiseLastError. SSB Framework(ABC) in effect. All Procs must execute in <2 seconds SSB Procs are sp_procs_ABC_*