Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 design for treeview-like structure

Author  Topic 

ronin2307
Posting Yak Master

126 Posts

Posted - 2007-06-07 : 17:50:22
ok i have a design question and since I am not a db designer I hope somebody can give me some insight into this...

I have an app that uses a treeview control to display a hierarchy of a machine assembly. Currently it only goes two levels deep (top level and a single subcomponent.
WHat I would like to do is enable my users to add n-deep levels to the top level machine. The problem with that is that I can't think of a way to store this in a DB and how the table(s) structure would look like.

It seems like this would be a classic problem in DB design, but that is where I lack knowledge so any help will be greatly appreciated

Thanx

mwjdavidson
Aged Yak Warrior

735 Posts

Posted - 2007-06-08 : 03:47:20
There's a few different ways of representing hierarchies. Probably the most straightforward is using a simple recursive relationship like this:
CREATE TABLE [dbo].[Component](
[ComponentID] [int] NOT NULL,
[ComponentDescription] [varchar](50) COLLATE Latin1_General_CI_AS NOT NULL,
[ParentComponentID] [int] NULL,
CONSTRAINT [PK_Component] PRIMARY KEY CLUSTERED
(
[ComponentID] ASC
))

ALTER TABLE [dbo].[Component] WITH CHECK ADD CONSTRAINT [FK_Components_ComponentID] FOREIGN KEY([ParentComponentID])
REFERENCES [dbo].[Component] ([ComponentID])


INSERT INTO component SELECT 1, 'Biggest Widget', NULL
INSERT INTO component SELECT 2, 'Big Widget A', 1
INSERT INTO component SELECT 3, 'Big Widget B', 1
INSERT INTO component SELECT 4, 'Widget C', 3
INSERT INTO component SELECT 5, 'Widget D', 3
INSERT INTO component SELECT 6, 'Widget E', 2
INSERT INTO component SELECT 7, 'Small Widget G', 5
INSERT INTO component SELECT 8, 'Small Widget H', 5


Mark
Go to Top of Page

madhivanan
Premature Yak Congratulator

22864 Posts

Posted - 2007-06-08 : 04:07:04
And refer this to know how to get data
http://www.nigelrivett.net/RetrieveTreeHierarchy.html


Madhivanan

Failing to plan is Planning to fail
Go to Top of Page

ronin2307
Posting Yak Master

126 Posts

Posted - 2007-06-08 : 09:09:33
very helpful. thank you both
Go to Top of Page

mwjdavidson
Aged Yak Warrior

735 Posts

Posted - 2007-06-08 : 09:40:28
no problem.

Mark
Go to Top of Page

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-06-11 : 00:19:19
One thing I would suggest is to separate your data model from your user interface. Starting to think of a database design around a tree view is dangerous - you need to consider all your business requirements first. Do you have more than one parent for each component for example, would you need to generate a pick list? etc. etc.
Separate the two and you'll find yourself writing much better products.
Go to Top of Page

ronin2307
Posting Yak Master

126 Posts

Posted - 2007-06-11 : 09:33:55
quote:
Originally posted by LoztInSpace

One thing I would suggest is to separate your data model from your user interface. Starting to think of a database design around a tree view is dangerous - you need to consider all your business requirements first. Do you have more than one parent for each component for example, would you need to generate a pick list? etc. etc.
Separate the two and you'll find yourself writing much better products.



please elaborate since there is talk about generating pick lists from this. Not sure how applicable it will be since i have to tie this to the ERP anyway, but I am interested in learning what you have to say. Thanx
Go to Top of Page
   

- Advertisement -