|
A rather odd join conundrum Either i have not had enough coffee this morning, or i have ran into a bit of strange join scenario. I have a CTE that's parsing millions of rows into a timesheet for a given weekending. This timesheet is going to be rendered in web pages, emails, binaries etc, and rather than writing rendering code for all the various interfaces we'de like to fetch the data from SQL in semi-timesheet esque form (i.e. a branch/mon/tue/wed columns etc): The problem here is that every day may have a varibale number of bookings (Note the NULL's), i.e. on tueday, branch 1 might have 2 bookings (2 rows) but only 1 booking on the monday. a stripped down version of my CTE is as follows: In the above CTE, BranchList contains 2 rows "001" & "002", BookingsMon 60 rows, BookingsTue 57 rows. By joining just BranchList & Bookings_Mon i get a 60 row result set with the branchID column correctly duplicated to reflect the greater number of matching rows on the join. However, as soon as i join in tuesday, things go mental as its obviously joining the 57 rows in tuesday onto the now 60 rows resulting in 3420 rows... Is there any way to do this kinda of side-by-side join in set based SQL, or am i going to have to go recursive? (temp tables, loops yada yada) Thoughts welcome.
(comments are locked)
|
|
Here's my attempt. I used PIVOT Good luck on the job search, looks like you have the drive and capacity to learn/think on your feet. I would add SharePoint 2010 dev to your list. Skip the LINQ2SQL, master the T-SQL dev and use stored procs instead. LINQ2Enities is useful. I don't have an opinion on Entity Framework, I just avoid it. I've done a lot of web development in the past and it is too tedious to be enjoyable for me but I do like Silverlight. Written several Silverlight Line-of-Business apps that are exposed in SharePoint. Peace
Dec 16 '11 at 03:57 PM
Scot Hauder
Thanks, Scot! That's good advice. It's all new to me after SQL Server 2000, so I appreciate the direction. I hadn't even thought about Silverlight.
Dec 16 '11 at 06:44 PM
Alendar
Unless you are an awesome web developer, which will include strong photoshop and flash skills--just focus on the basics. In your case I say know basic ASP.NET and some silverlight but master the database side. Anyone can write some crappy, inefficient asp.net or c# and its performance will still be acceptable. The real strength comes in knowing set-based solutions instead of cursors or loops. And in the case of the solution above, CTE's are performance killers and, while easier to read, they are more performant expressed as derived/sub queries.
Dec 16 '11 at 10:18 PM
Scot Hauder
It seems like it would create a lot of duplicate code, and I'm not sure SQL Server would come up with a different plan. Temp tables would be my next guess if performance was an issue.
Dec 17 '11 at 12:27 PM
Alendar
(comments are locked)
|
|
Right, i think ive found the best way to do this! Ive created a new primary key to join on by putting the following in the WeeksBookings expression: This gives me a unique number per weeknumber & branch, i then revised the BranchList expression as follows: I then joined the weeks on the weeknumber AND this new JoinID, this works perfectly: @HeavenCore I do not think this is the best solution. I cannot find any good reason to make several joins when a single join can do the job. Anyways, at the end it is your decision which matters. :)
Dec 18 '11 at 10:38 PM
Usman Butt
@Usman Butt Hello there, whilst your CASE method offers a slightly faster execution, it also results in massive amounts of rows, for instance, say there was 20 rows per day in the WeeksBookings expression, your method would get a 140 row result with all but one set of the days being NULL. Whereas my method returns a 20 row result set. I agree mine is slower, but won’t require a second phase to group up the data. The DDL I provided in my opening question + the revised CTE in this answer vs your case solution demonstrates this issue. I hope that makes sense :)
Dec 19 '11 at 01:44 AM
HeavenCore
@HeavenCore Sorry, but I cannot follow the external link for some reasons. If you can put some dummy data (which would return 20 rows as you stated for your code), my gut feeling is that can still be achieved with two joins or may be in one query.
Dec 20 '11 at 01:29 AM
Usman Butt
(comments are locked)
|
|
If I were you, I would use CASE statement to get the desired output. No need of joins. If you would have provided the sample data and DDLs, I could have been more certain. You should do something like this Hope it helps. I was working on some sample data (I’m working on a dev copy of live data, so had to do some serious anonymizing (sp?) and stripping of sensitive data, your solution beat me to it! But as for your solution, it works perfectly! Well done!
Dec 16 '11 at 05:57 AM
HeavenCore
(comments are locked)
|


can you provide table DDL and some sample data please?
@Fatherjack Sure can, might be a bit chunky, what is the best way to post it? (You’ve advised me not to post external links it the past)
we would only need a few rows. enough to show how you want things summarised. as for the DDL, thats a bit trickier if the objects are big
@Fatherjack Ive created a DDL & sample data dump, you can grab it here: http://www.heavencore.co.uk/filehub/uploaded/SchemaAndSampleData.sql apologies for the link (its my website) but the sample data is really needed to demonstrate the problem. I'm still looking for a good solution, as Usmans solution below results in massive amounts of empty cells.