|
Once again it is time for a Phil Factor Speed Phreak Challenge and the prize is now a $100 Amazon voucher, and the privilege of displaying this rather nice trophy jpg on your blog / website / bedroom wall.
This time your task is simply to produce a summary report of the cost of international phone calls made within an organization on a week by week basis for both Users and Offices. You are allowed to use any method you see fit, you may also add any indexes, table-functions or views that you wish (though not an index view). Creation of these will not count to the overall execution time. If you are unsure if what you want to do might disqualify you, then please post a comment. The table CallLog contains the log of every phone call, including which user called which number, when the call started and ended, and the office the user was in at the time. You will notice that it is not well normalized, since it is actually a view taken from several tables. Users are never in a fixed office, and can move from office to office at any point. Calls with a CallEnd equal to CallStart were not answered and can be safely ignored. To calculate the cost of the call you need to use a lookup within the PhoneTariff table. The calls are prefixed by an area code corresponding to a country. You must note that many of the call areas have the same starting character sequence , so calls made to numbers starting '35191' must be priced using the tariff of '35191' not '351'. There is a rather elaborate charging system according to the length of the call. This means that you need to calculate the cost of the call as the minute by minute cost changes with the length of the call. These must be summed. Looking at the PhoneTariffCharges table
The first 8 minutes of the call will be 0.4792 per minute. 9 to 31 minutes will be 0.18 per minute 32 to 59 minutes will be 0.5702 per minute etc.... All ranges have a UpToXMinutes of 9999 so you dont need to worry about an upper limit. The calllength is rounded upto the nearest whole minute. Here is the DDL to create the tables
and heres the link to the data. Use
to load the data in. Heres the solution provided by our mediocre developer Robert Bar, please note a fix for an issue with the week number being taken from @CallEnd.
Here are some guidelines for your entries: 1) Include a header in your suggestion. Make sure your name and the current date is present. 2) Include an edition number. First edition is 1. If you later improve your current suggestion post it again as version 2. Example: “Peso 1” and if improved, “Peso 1b”, “Peso 1c” etc. 3) If you are trying a new algorithm, change the edition to “Peso 2”. If you improve this algorithm, change the version to “Peso 2b”, “Peso 2c” etc. This will save Phil hours of work in the test harness! 4) The solution must clear up all its mess (temporary tables, indexes, etc.) so it can be re-run without errors. As ever Phil Factor will be final judge. The closing date will be midnight Thursday 17th December London
(comments are locked)
|
|
-----Author Sampath Natarajan I posted my code and it did not appear neat. How to post it so it appears neat and clear. Thanks Sampath
Sep 14 '10 at 03:02 PM
Sampath
(comments are locked)
|
|
I would like to have a stab at this and future challenges also but I would like to know how to time my script. What is the method that is being used? Well, we started off just timing the runs using the default timer you get in any client application - but we found that wasn't sufficient, so I ended up writing a test harness in C# that used a high-resolution timer to determine how long things were taking. Drop me a mail on mattw [at] code9 [dot] net and I'll send you a copy if you like...
Feb 09 '10 at 06:03 PM
Matt Whitfield ♦♦
Thanks Matt I would really appreciate that. I will send you an email right away.
Feb 09 '10 at 06:45 PM
Ian Roke
(comments are locked)
|
|
Unfortunately I haven't had time to come up with a solution of my own... seems like it would be hard to compete with the ones provided so far though... some very nice coding. One thing I would like to mention as I don't think it has been, is that some of the solutions (Peso v4 family for example) take advantage of the fact that the CallAreas exist for the duration of the reporting period, so while they do solve the problem at hand, they may not be suitable for a real solution. I believe that if for example CallArea 35191 was not introduced as a separate phone tarrif until after the first call using it was made... rather than the call being charged at the 351 rate, it would not be charged at all. That is the call log would still match to the 35191 code, but when calculating the charge (connection mainly), there would be no record for it in the PhoneTariff matching the date range, causing the call to be 'forgotten' and not charged at all (some versions may just miss the connection charge). Of course this is all irrelevant, if when a new CallArea is introduced that it gets a back-dated copy of the tariff it was derived from (in this case a copy back to the start of the records of the 351 rate), or if indeed the list we were given was a view that ensured all tariffs were valid for the whole of the reporting period. For the problem at hand though, it's a nice trick that I'm sure sped up the results.
(comments are locked)
|
|
Figured out the various problems. I believe that some of the other solutions may not be including the ConnectionCharge in totals. Also was excluding about 10,000 UserNames because of the old datetime as a date + 00:00:00 not including if same date but time past midnight problem. Casted the CallStart to date before doing BETWEEN. I used lmu92's same indexes (thanks!).
Code:
Same as lmu92's cleanup (thanks again!): Gah. Code is seriously messed up! Will try and fix.
Dec 17 '09 at 12:38 PM
Bluedog67
Ah I know why code is flaking out... gt and lt characters.
Dec 17 '09 at 12:44 PM
Bluedog67
SELECT DATEPART(week, '2008-01-13 00:00:00') equals 3? In SQL 2008 Dev Edition. Huh?
Dec 17 '09 at 02:39 PM
Bluedog67
"DatePart(Week..." is regional dependent. What is your SET LANGUAGE setting? What is your SET DATEFIRST setting?
Dec 17 '09 at 02:51 PM
Peso
SET DATEFIRST has impact on DATEPART(week, C.CallStart). Which also affects numbers.
Dec 17 '09 at 03:19 PM
Bluedog67
(comments are locked)
|
1 2 3 4 next page »


Can we be specific about how timings will be done? Average of x runs with a dropcleanbuffers before each? Average of x runs with a dropcleanbuffers before the first run?
What about Abel Buck? His call was 0.000 seconds and thus no charge for length of call, but is he still going to pay for the connection of 52 cents?
I am tryting to find a 100% correct answer but sometimes i doubt if the answer privided by Robert Bar is 100% Correct. Should we take his answer as the final results or should we try to prove that there could be something wrong with it and propose something new ?
With regard to Abel Buck the call was not answered and therefore no charge. "Calls with a CallEnd equal to CallStart were not answered and can be safely ignored." The Robert Bar solution should be correct. If there are any issues with a calculation please PM me and ill manually double check.
I took a random case, number dialled: 980913853342, according to Robert Bar he used area code 980 and number 91-385-3342 (formated 2,3,4) ["order by len(CallArea) desc"], but you could also get area code 98 and number dialled 091-385-3342 ( formated 3-3-4 ). My point is that phone numbers of 12 digits ( this case ) should have just 2 chars on area code, those with 13 digits, have 3 chars as area code and so on, so the remaning number will still be formated 3-3-4 and not [1..3]-3-4. Meaning that the proposed solution could not be the corret one...