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 «««1234

get the first and last day of any Year/Month Expand / Collapse
Author
Message
Posted Friday, March 1, 2013 2:30 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:50 PM
Points: 2,090, Visits: 3,142
Lynn Pettis (3/1/2013)
ScottPletcher (3/1/2013)
Jeff Moden (3/1/2013)
ScottPletcher (3/1/2013)
[quote]
Code reuse is another tricky subject. It generally gets talked about far more often than it is genuinely done. A few developers are bad enough, but trying to get hundreds of developers to build and use reuseable code is like trying to get Congress to agree on something.


Companies that have "hundreds of developers" will also have code libraries and standards to follow. Usually, the first standard is to check the library for code simply because eliminates testing because the code is already approved. That saves money and development time.



Very easy to say, extraordinarly hard to do in actual practice.

You have to determine in an existing needed function, say, already exists. Verify that it does indeed do what you are looking for, without unacceptable side effects, etc..


So, instead of doing all that, just keep reinventing the wheel, right?



I'm saying it's a massive effort to set up properly, and, more significantly, to train developers and others to use properly.

Some companies that have tried it have discovered that for much of the code, it actually cost them more time to find and reuse existing code than to write new code.

There is no perfect method for sharing code that everyone automatically knows all code that is available for reuse and when to use it.

Again, it's very easy to glibly posit that everyone should do that. It's vastly harder to actually set up it and make it work well.

The real world has a way of destroying easily-imagined fantasies.


SQL DBA,SQL Server MVP('07, '08, '09)

"While in these days of quiet desperation /
As I wander through the world in which I live /
I search everywhere for some new inspiration /
But it's more than cold reality can give /
If I need a cause for celebration /
Or a comfort I can use to ease my mind /
I rely on my imagination /
And I dream of an imaginary time" : the inimitable Mr. Billy Joel
Post #1425755
Posted Friday, March 1, 2013 2:44 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 10:00 AM
Points: 37,099, Visits: 31,650
ScottPletcher (3/1/2013)
C'mon, be real, that code is clear enough that a decent developer will understand what it means. Anyone who's developed for SQL for any period of time understands that SQL's base date is 1900.


Since you've worked for a company with "hundreds of developers", I'm genuinely surprise by your "be real" comment. You'll find many so called "decent" developers that get hired into a company of that size that don't even know what DATEADD is never mind that 1900 is the base date for an underlying serial number.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1425757
Posted Friday, March 1, 2013 2:57 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 10:00 AM
Points: 37,099, Visits: 31,650
ScottPletcher (3/1/2013)

Highly obscure coding practices to gain a few milliseconds per 100K+ rows, when realistically only 5,000 rows will ever be processed, just causes maintenance issues.


Then you should never use things like a Tally table or a difference between row numbers for performance.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1425763
Posted Friday, March 1, 2013 2:57 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:50 PM
Points: 2,090, Visits: 3,142
Jeff Moden (3/1/2013)
ScottPletcher (3/1/2013)
C'mon, be real, that code is clear enough that a decent developer will understand what it means. Anyone who's developed for SQL for any period of time understands that SQL's base date is 1900.


Since you've worked for a company with "hundreds of developers", I'm genuinely surprise by your "be real" comment. You'll find many so called "decent" developers that get hired into a company of that size that don't even know what DATEADD is never mind that 1900 is the base date for an underlying serial number.



That's a self-contradictory claim. By definition, a decent T-SQL developer would know what DATEADD is. A decent developer that develops professionally with TSQL for a period of time would at least know that DATEADD is.

Int'l Paper was a $25B+ company at the time, with over 100,000 employees (I think they're down to 70K now). If you want to imply that a company that size would not have "hundreds of developers", that's your choice. I won't bother with FedEx, as I assume you'll make the same unsupported "asnides" about them as well. As for myself, I won't imply that people are liars w/o some actual evidence.

Patently silly claims, otoh, can easily be identified a priori as false.


SQL DBA,SQL Server MVP('07, '08, '09)

"While in these days of quiet desperation /
As I wander through the world in which I live /
I search everywhere for some new inspiration /
But it's more than cold reality can give /
If I need a cause for celebration /
Or a comfort I can use to ease my mind /
I rely on my imagination /
And I dream of an imaginary time" : the inimitable Mr. Billy Joel
Post #1425764
Posted Friday, March 1, 2013 5:24 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 10:00 AM
Points: 37,099, Visits: 31,650
ScottPletcher (3/1/2013)
Jeff Moden (3/1/2013)
ScottPletcher (3/1/2013)
C'mon, be real, that code is clear enough that a decent developer will understand what it means. Anyone who's developed for SQL for any period of time understands that SQL's base date is 1900.


Since you've worked for a company with "hundreds of developers", I'm genuinely surprise by your "be real" comment. You'll find many so called "decent" developers that get hired into a company of that size that don't even know what DATEADD is never mind that 1900 is the base date for an underlying serial number.



That's a self-contradictory claim. By definition, a decent T-SQL developer would know what DATEADD is. A decent developer that develops professionally with TSQL for a period of time would at least know that DATEADD is.

Int'l Paper was a $25B+ company at the time, with over 100,000 employees (I think they're down to 70K now). If you want to imply that a company that size would not have "hundreds of developers", that's your choice. I won't bother with FedEx, as I assume you'll make the same unsupported "asnides" about them as well. As for myself, I won't imply that people are liars w/o some actual evidence.

Patently silly claims, otoh, can easily be identified a priori as false.


C'mon Scott. "Decent" was in quotes and I never suggested nor even implied that you were a liar.

I guess we'll have to agree to disagree. You agree to giving up on some aspects of performance for the sake of readability and I suggest that a simple comment in the code will give you both.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1425792
Posted Monday, March 4, 2013 1:59 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 9:57 AM
Points: 2,854, Visits: 5,120
Ough!
Gentlemen, no needs to argue so much on this subject. I guess everyone involved in this discussion is right on some points. 1900 is definitely more recognisable than 22800, however small comment comment like "22800 = 1900 * 12" would do enough to explain. It's possible and highly advisable to write reusable code (even for your own re-use purposes), but in the same time it's impossible to enforce code reuse in a large organisations, so re-inventing the wheel is a almost everyday developer's procedure (eg. non-sql ones).
And on the bright note, I have some topic idea for your Congress:
.... like trying to get Congress to agree on something.

What about "Double congressmen salary"? That should not take too much troubles to agree upon.
Yeah, I know it would be couple of idiots there who will try to play "good guy" saying something against this great idea, but for some reason, I think, they will be convinced to vote YES in matter of hours!



_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!"
(So many miracle inventions provided by MS to us...)

How to post your question to get the best and quick help
Post #1426127
Posted Monday, March 4, 2013 4:10 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, September 5, 2014 11:40 AM
Points: 246, Visits: 1,169
Lynn Pettis (3/1/2013)
I'll have to disagree with you and side with Jeff. I have learned much from him and scalability and reuse actually come hand in hand. If you take the time now to build scalable code (read routines) that can be reused then spend the time. Just because it is good enough for a particular use does not mean it will be for another. Many times people will take what you have written and use it where it really shouldn't because it was just good enough for that one instance.


If you have a limited amount of time, spend your time on the code which goes into (onto) the production system.

I use a huge amount of queries studying the database and effects of code on the database (performance, frequency studies, fragmentation). I try to write these queries fast (and unoptimised). Yes sometimes I wait for two minutes and sometimes I improve those queries.

And Yes this forum is of great value, for both production systems (were efficiency counts) and for producing code which works fast enough for non production systems. Often good code and readability goes hand in hand. But sometimes readability is offered to increase efficiency. But if I have to make a choice readability is of greater importance except if performance really matters. But this forum has attention for that as well. For me this forum is of more importance to learn and produce the code myself than, allthough I often use code of this forum as wel, which is also of great value.

Thanks all for taking part in this thread,
ben

Post #1426166
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse