June 2, 2014 at 9:07 am
joe.eager (6/2/2014)
ORM'sUncommented code
+10
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 2, 2014 at 10:03 am
*Rubbing hands together with glee*
SSIS pet peeves:
...and many more, though I don't want to bore anyone. These are just the ones that popped into my head immediately.
T-SQL pet peeves:
That's all I have for now.
June 2, 2014 at 10:14 am
Many good items listed in the posts above, but I missed one that is a real pet peeve for me:
- leading ; when defining a CTE. Sorry, but semicolons are statement terminators, not statement beginanators.
June 3, 2014 at 11:50 am
A great list discussion - my 3 cents:
- table variables need to be depracated with extreme prejudice
- SSMS generated code (IMAX screen width anybody ?)
- UpperLowerCase as opposed to Upper_Lower_Case (ya got 128 characters, use 'em for clarity)
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
June 3, 2014 at 12:03 pm
Rudyx - the Doctor (6/3/2014)
A great list discussion - my 3 cents:- table variables need to be depracated with extreme prejudice
- SSMS generated code (IMAX screen width anybody ?)
- UpperLowerCase as opposed to Upper_Lower_Case (ya got 128 characters, use 'em for clarity)
Alright, whats the matter with table variables? And additionally, for me they're the go to for saving info during a transaction that might roll back, so what would be your alternative strategy here?
June 3, 2014 at 12:11 pm
patrickmcginnis59 10839 (6/3/2014)
Rudyx - the Doctor (6/3/2014)
A great list discussion - my 3 cents:- table variables need to be depracated with extreme prejudice
- SSMS generated code (IMAX screen width anybody ?)
- UpperLowerCase as opposed to Upper_Lower_Case (ya got 128 characters, use 'em for clarity)
Alright, whats the matter with table variables? And additionally, for me they're the go to for saving info during a transaction that might roll back, so what would be your alternative strategy here?
I agree, table variables have their use. They shouldn't be deprecated but they shouldn't be abused either.
June 3, 2014 at 12:29 pm
What is wrong with table variables ?
hmmm ...
table variables are not capable of having indexes (however they support constraints and primary keys)
no indexes mean:
- no index statistics for the optimizer
- no indexes or index statistics which translates to mean a table scan for all access
- no indexes also mean that inserts with a constraint cause a table scan for every insert (the more rows the longer the scan)
Oh, and the initial fallacy that they are memory resident (HAH) - try:
select name
from tempdb..sysobjects
where name like '#%'
as for holding data in a roll-back scenarirollbackis wrong about using regular temp tables ?
anyone else ? did I miss something ?
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
June 3, 2014 at 12:32 pm
Rudyx - the Doctor (6/3/2014)
What is wrong with table variables ?hmmm ...
table variables are not capable of having indexes (however they support constraints and primary keys)
no indexes mean:
- no index statistics for the optimizer
- no indexes or index statistics which translates to mean a table scan for all access
- no indexes also mean that inserts with a constraint cause a table scan for every insert (the more rows the longer the scan)
Oh, and the initial fallacy that they are memory resident (HAH) - try:
select name
from tempdb..sysobjects
where name like '#%'
as for holding data in a roll-back scenarirollbackis wrong about using regular temp tables ?
anyone else ? did I miss something ?
There are some issue with table variables. For small amounts of data they are fine.
The point of a rollback is that if you populate a temp table inside a transaction and then rollback you also rollback your temp table. A table variable on the other hand will still contain whatever data it had previously.
There are times when a table variable is the appropriate and preferred mechanism for storing data in a temporary location. Much like cursors, they have a valid usage but get overused/abused by people who don't understand what they do.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 3, 2014 at 1:09 pm
My greatest pet peeve of all is what some people claim to be "best practices".
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 1:21 pm
Jeff Moden (6/3/2014)
My greatest pet peeve of all is what some people claim to be "best practices".
That's funny you would say that, we have been told we need to start following 'Best Practices'. So I say "How do you define that?" and "What version?".
Another coding style I dislike is having extra spaces between parts of the SQL. Or not following the same format for all joins.
SELECT field1, field2
-- No need for blank line here
INTO #whatever
-- No need for blank line here
FROM table_name l inner join other_table r ON -- follow the same formatting you do below!!
l.field_id = r.field_id
-- No need for blank line here
LEFT JOIN new_table nt ON
l.field_id = nt.field_id
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 3, 2014 at 1:22 pm
Jeff Moden (6/3/2014)
My greatest pet peeve of all is what some people claim to be "best practices".
The plural makes it sound like polygamy
😎
June 3, 2014 at 1:28 pm
SQL is delicious (6/2/2014)
*Rubbing hands together with glee*SSIS pet peeves:
- SSIS packages where tasks/containers/etc. have names like Foreach Loop Container1, Foreach Loop Container2, Data Flow Task, OLE DB Command 1, Execute SQL Task, etc. Lazy. Give them meaningful names, please.
- Variables anywhere named var1, var2, var3, etc. Stop that.
- Silly descriptions like "Awesome" or "Bob is the best" in SSIS objects. Just please don't.
- No annotations in SSIS packages.
...and many more, though I don't want to bore anyone. These are just the ones that popped into my head immediately.
+1
I'll add to that:
* no respect for layout whatsoever, which leads to the SSIS package looking like a spider web
* use of OLE DB commands
* use of the SCD wizard
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 3, 2014 at 1:28 pm
Lynn Pettis (6/2/2014)
Many good items listed in the posts above, but I missed one that is a real pet peeve for me:- leading ; when defining a CTE. Sorry, but semicolons are statement terminators, not statement beginanators.
+ 1000
That is annoying 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 3, 2014 at 1:32 pm
Sean Lange (6/3/2014)
Rudyx - the Doctor (6/3/2014)
What is wrong with table variables ?hmmm ...
table variables are not capable of having indexes (however they support constraints and primary keys)
no indexes mean:
- no index statistics for the optimizer
- no indexes or index statistics which translates to mean a table scan for all access
- no indexes also mean that inserts with a constraint cause a table scan for every insert (the more rows the longer the scan)
Oh, and the initial fallacy that they are memory resident (HAH) - try:
select name
from tempdb..sysobjects
where name like '#%'
as for holding data in a roll-back scenarirollbackis wrong about using regular temp tables ?
anyone else ? did I miss something ?
There are some issue with table variables. For small amounts of data they are fine.
The point of a rollback is that if you populate a temp table inside a transaction and then rollback you also rollback your temp table. A table variable on the other hand will still contain whatever data it had previously.
There are times when a table variable is the appropriate and preferred mechanism for storing data in a temporary location. Much like cursors, they have a valid usage but get overused/abused by people who don't understand what they do.
I have to agree with Sean here, use the right tool for the job.
As for an alternative, you could go with Oracles autonomous transactions could be a possibility.
June 3, 2014 at 2:26 pm
Jeff Moden (6/3/2014)
My greatest pet peeve of all is what some people claim to be "best practices".
"Best practices" is pretty much a key phrase that helps gather recommendations together regarding technologies and I'm not really getting why anybody would object to it. Sure, if there are objectively bad recommendations listed under a title "best practices" then I can get that, but otherwise, "best practices" is really just another name for "recommendations" that is probably more google friendly.
So whats the beef with "best practices"?
Viewing 15 posts - 31 through 45 (of 272 total)
You must be logged in to reply to this topic. Login to reply