Maxus wrote:
> Hi People,
>
> I'm in the lucky position of building a database from scratch for my
> company in SQL 2005. We have a situation where we have customers and
> each customer can have a child customers and so on and on.
>
> So the best way I found of doing this was putting everything in one
> table called "Customer" each row stores a parentId that links to the ID
> of the parent customer. If the customer doesn't have a parent its ID
> its parent ID is set to match its own ID (So I can use a relationship
> to prevent bad id's from being added). This allows me to use the new
> SQL 2005 recursive functions.
>

> Is this a good way of solving the requirement or does anyone have a
> better way of doing it? I eventually want to do the same thing with the
> items table where each item can be a child of another but it currently
> has over 2mil+ records and I'm worried this could slow everything down.
>

"Maxus" <rtypestudios@gmail.com> wrote in message
news:1147934903.241630.282640@u72g2000cwu.googlegroups.com...
> Hi People,
>
> I'm in the lucky position of building a database from scratch for my
> company in SQL 2005. We have a situation where we have customers and
> each customer can have a child customers and so on and on.
>
> So the best way I found of doing this was putting everything in one
> table called "Customer" each row stores a parentId that links to the ID
> of the parent customer. If the customer doesn't have a parent its ID
> its parent ID is set to match its own ID (So I can use a relationship
> to prevent bad id's from being added). This allows me to use the new
> SQL 2005 recursive functions.
>
> Is this a good way of solving the requirement or does anyone have a
> better way of doing it? I eventually want to do the same thing with the
> items table where each item can be a child of another but it currently
> has over 2mil+ records and I'm worried this could slow everything down.
>
> Thanks for you help!
> -Alex
>