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 12»»

Everybody Reports to Somebody Expand / Collapse
Author
Message
Posted Tuesday, May 15, 2007 10:30 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 30, 2010 10:08 PM
Points: 3, Visits: 6
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/cHatley/3001.asp
Post #366185
Posted Sunday, June 3, 2007 9:36 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, September 15, 2014 5:20 PM
Points: 1,276, Visits: 1,134

Ahhh, ye olde adjacency list model.  You might get better efficiency from a set-based solution, like the nested sets model or one of its variants.  Here's an Q&D sample.

CREATE TABLE #Employees (ID INT PRIMARY KEY,
 LastName VARCHAR(30),
 FirstName VARCHAR(30),
 LeftID INT,
 RightID INT)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (1, 'Smith', 'John', 1, 24)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (2, 'Johnson', 'Bob', 2, 15)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (4, 'Fields', 'Sue', 3, 4)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (3, 'Burton', 'Debra', 16, 23)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (5, 'Jacobs', 'Todd', 11, 14)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (6, 'Sanders', 'Mary', 5, 10)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (10, 'Sims', 'Tom', 17, 18)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (11, 'Wright', 'Larry', 19, 20)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (12, 'Morgan', 'Betty', 21, 22)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (7, 'Teeter', 'Sandy', 12, 13)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (8, 'Morris', 'Megan', 6, 7)

INSERT INTO #Employees (ID, LastName, FirstName, LeftID, RightID)
VALUES (9, 'Binks', 'Randy', 8, 9)
GO

CREATE PROCEDURE dbo.GetOrgChart (@startID INT)
AS
BEGIN
 SELECT e1.ID, e1.LastName, e1.FirstName, e1.LeftID, e1.RightID, COUNT(e2.ID) AS Level
 FROM #Employees e1
 INNER JOIN #Employees e2
 ON e1.LeftID BETWEEN e2.LeftID AND e2.RightID
 WHERE e1.LeftID BETWEEN (SELECT LeftID FROM #Employees WHERE ID = @startid)
  AND (SELECT RightID FROM #Employees WHERE ID = @startid)
 GROUP BY e1.ID, e1.LastName, e1.FirstName, e1.LeftID, e1.RightID
 ORDER BY e1.LeftID
END
GO

EXEC dbo.GetOrgChart 1

Post #370914
Posted Monday, June 4, 2007 2:54 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, October 30, 2008 3:10 AM
Points: 6, Visits: 20

Oracle has "Connect by prior"

select * from person connect by prior id=supervisor_id

.. it makes traversing hierarchies trivial.

I was hoping it would appear in SS2005... 

Post #370935
Posted Monday, June 4, 2007 3:49 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, August 10, 2010 4:54 AM
Points: 815, Visits: 32

Hi Mike,

apologies for this, but i am interested in your right-brain set based solution, but I am feeling a bit left-brain this Monday morning, probably lack of coffee, so please could you set me right about what left-id and right-id represent because at the moment I'm feeling a bit left-out.

Thanks

David



If it ain't broke, don't fix it...
Post #370941
Posted Monday, June 4, 2007 4:05 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, January 21, 2014 3:55 AM
Points: 92, Visits: 223
Quite liked that one, though as surprised as you at the efficiency. Will give it a bash sometime.
Post #370944
Posted Monday, June 4, 2007 7:18 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 29, 2013 5:29 AM
Points: 104, Visits: 721
Mike's example is actually a nested set model, not an adjecent list model per the article. Basically instead of having a "boss" column in your employee table that's the same as an employee, each employee has containment information. You use two columns which represent the range of containment, a set, an employee has. Joe Celko explains it better, http://www.developersdex.com/gurus/articles/112.asp.
Post #370991
Posted Monday, June 4, 2007 7:49 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, August 10, 2010 4:54 AM
Points: 815, Visits: 32

Hi Tim,

Thanks for that link to Joe Celko's article, I had not come across this solution before. I can see that it is easier to model an org tree in SQL using set theory. In practice, does the data in the set correspond to an organisation's departmental structure, rather than individual relationships, otherwise you could get real problems if an employee switches managers and correspondingly needed to switch containments?

I like the idea that because the containment encapsulates all levels of the hierarchy, there is no break in the management chain if an employee in the middle-tier leaves, the model is effectively self-healing.

Presumably by creating overlapping sets you could also create organisation structures where individuals have multiple lines of management (many DBAs may be familiar with this    )

David



If it ain't broke, don't fix it...
Post #370998
Posted Monday, June 4, 2007 7:52 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 30, 2010 10:08 PM
Points: 3, Visits: 6

Hi Mike,

   Although your solution is a viable option (and we considered it), we chose to identify each employee's manager as a single field on each record because we wanted the ability to easily update this information to accomodate the incredible growth of our organization.  With the method we are using, we basically complete this single piece of information (manager's user ID) for each new employee during the account setup process and we are good to go. 

 

Post #371000
Posted Monday, June 4, 2007 8:14 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, August 10, 2010 4:54 AM
Points: 815, Visits: 32

Hi Mike,

found a further article at http://www.intelligententerprise.com/001020/celko1_1.jhtml

It appears that if your organisation structure fequently changes, you would still need an adjacency list to calculate the nested sets though? Joe provides the code to convert one to the other. I guess the practical application of this solution  would be to write a trigger which recalculates the nested sets whenever the organisation structure is changed (i.e. you change an employee's manager id), storing the left and right values you calculate and using them as an aid to produce faster organisation structure reports.

If someone left the organisation, you would leave the existing calculated left and right values in place to provide a management hierarchy until a new manager was appointed.

PS: Have had several coffees now

David



If it ain't broke, don't fix it...
Post #371007
Posted Monday, June 4, 2007 9:04 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 30, 2010 10:08 PM
Points: 3, Visits: 6

Hi,

   I have received a private question asking about how to deal with employees that may report to multiple bosses and I wanted to provide my thoughts on the subject.  I think the best approach to address this issue would be to move the 'Manager User ID' field to a separate table containing at least the 'User ID' and 'Manager User ID' columns which could be joined to the 'Employee' table via the 'User ID' column.  You could then modify the stored procedure to include the new table via a join such as (Changes Highlighted In Yellow) . . .

CREATE PROCEDURE select_subordinates_by_manager
@UserID int
As
Set NoCount On

Declare @UserCount int
Set @UserCount = 1

Create Table #In (UserID int)
Create Table #Out (UserID int)
Create Table #Result (UserID int)

Insert Into #In (UserID) Values (@UserID)
Insert Into #Result (UserID) Values (@UserID)

While @UserCount > 0
Begin
Insert Into #Out (UserID)
Select Distinct UserID From Test..Employee as e
Join Test..ManagedBy as m on m.UserID = e.UserID
Where m.ManagerUserID In (Select UserID From #In)
Select @UserCount = (Select Count(UserID) From #Out)
If @UserCount > 0
Begin
Insert Into #Result (UserID)
Select UserID From #Out
End
Delete From #In
Insert Into #In
Select UserID From #Out
Delete From #Out
End

Set NoCount Off

Select UserID From #Result

Post #371023
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse