|
I'd be hard pushed to describe any of this as logic!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Actually, the little bit I looked at today had rafts of queries of the form..
INSERT INTO TEMPTABLE (A, B, C, D, 'OBJ TYPE 1')
SELECT A, B, C, D
FROM MASTERTABLE
WHERE OBJTYPE = 1 ' OBJ TYPE 1
INSERT INTO TEMPTABLE (A, B, C, D, 'OBJ TYPE 2')
SELECT A, B, C, D
FROM MASTERTABLE
WHERE OBJTYPE = 2 ' OBJ TYPE 2
(without the comment. Theres absolutely zero comments)
Rinse and repeat for a further 13 object types, then apply a set of 15 update queries to the result based on other selections based on the same types. If I ever have to get my hands dirty, I'll begin by refactoring those out to other procedures, and use a parameter to specify the object type - that's if I can't do the same thing more efficiently by GROUP BY in some way. Hopefully after a while some wood will begin to emerge from the trees.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Put that BACK!
Nicholas Marty wrote: What?
The pish you just took! 
speramus in juniperus
|
|
|
|
|
I was further amazed to discover the guy who wrote it (used to work for a third party who used to do the development) now works for Microsoft!
I did joke that maybe his job is to push their query optimisation team to the limits. 
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
|
Does the stored procedure do the job it was intended to do?
Does it make business sense to decouple it and break it down into smaller pieces?
If it works, and doesn't need to be decoupled, then where is the issue?
|
|
|
|
|
Tim Carmichael wrote: then where is the issue?
it takes 8 hours to run...
|
|
|
|
|
Apparently, about 18 months ago it took a couple of hours. At this rate, we soon won't be able to run it overnight, as our database doesn't tend to get smaller over time!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Is the growth in execution time linear or exponential?
Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers.
Buckminster Fuller
|
|
|
|
|
I don't know yet, I only have 2 data points.
(and one of them is fairly rough - I only know exactly for the latest few runs)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
At present it kind of works. Our system deals with a number of types of object, if a new type is added, we will need to maintain it. Nobody has been brave enough to tackle the thing, and no one really understands how it works. But apart from that, all is hunky dory.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Just call it magic and back off slowly.  And don't turn your back on it until you're out of sight!! 
|
|
|
|
|
Convert.ToInt32(Int32)[^]
Quote: Returns the specified 32-bit signed integer; no actual conversion is performed.
Most useful method evar....
modified 27-Nov-13 14:00pm.
|
|
|
|
|
What do you expect? Convert.ToInt32(Int32) does nothing, you are trying to point it out as a joke, but its actually quite useful especially when you don't know the type that you are passing into it (which is why Convert has so many ToXXX overloads). Convert.ToDouble(Double) is the same, as well as Convert.ToSingle(Single), etc.
|
|
|
|
|
Hmm... totally missed this usage case, you're right. More often than not though, I use the Convert class to convert objects where I do know what I'm passing in, so it just struck me as odd when I was browsing documentation. I feel like they could have mentioned this in the remarks rather than a 'nothing happened' remark.
|
|
|
|
|
There are even more usage scenarios than that, take for example the following code:
public void SomeDummyMethod(int myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Now, lets say later down the line you get somebody who says "wait, myNumber needs to be a signed byte!"...
Well now you only have to change one line of code:
public void SomeDummyMethod(SByte myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Then later somebody comes around and says, "no, it should be a double to begin with"...
public void SomeDummyMethod(double myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
This is an overly simplified case obviously, but imagine if there were 100 or 200 lines of code in the function, if they didn't have Convert.ToDouble(double) the one change at the top would break unknown lines of code below.
Plus, the design strategy for the class was Convert should convert from any numeric type any other numeric type. Oddly enough that also means converting from something back to itself...
On top of all that, it really helps support the IConvertable [^]interface later on, and even says in the documentation:
"The common language runtime typically exposes the IConvertible interface through the Convert class. The common language runtime also uses the IConvertible interface internally, in explicit interface implementations, to simplify the code used to support conversions in the Convert class and basic common language runtime types."
So much more useful than you think 
|
|
|
|
|
public void SomeDummyMethod(double myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
And after few months someone finds this code and posts it to Weird and Wonderful. 
|
|
|
|
|
What, you can't return a double as void?
|
|
|
|
|
Ron Beyer wrote: public void SomeDummyMethod(int myNumber)
{
double myDouble = Convert.ToDouble(myNumber);
return myDouble * 1000.1f;
}
Apart from the fact that you can't return a value from a void method, why are you multiplying a double by a float constant?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
He doesn't want it to sink without trace...
|
|
|
|
|
OriginalGriff wrote: He doesn't want it to sink without trace...
...into the void.
Greetings - Jacek
|
|
|
|
|
Best to avoid the Convert class generally; the only useful member is ChangeType.
|
|
|
|
|
Ron Beyer wrote: Convert.ToInt32(Int32) does nothing
but to throw exceptions... Prefer Int32.TryParse instead.
|
|
|
|
|
|
Btw. a method Convert.ToSingle(Double) always makes me feel sad.
Greetings - Jacek
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
