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
 SQL Server 2000 Forums
 SQL Server Development (2000)
 Database Design: Intentionally Duplicating Tables

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2002-04-12 : 09:08:19
Philip writes "When adhering to normalization principles, it's not a standard practice to duplicate tables and their data. I have the following design challenge and wanted feedback on the best implementation:

Currently, there exists a master product table. Clients using this co-branded Web app must have the ability to modify, add, delete products according to the specifications below. The idea is that a duplicate table will be created for each client that the client can modify.

1) Clients can add products to their table from the master table, but they don’t have to — they can add products manually if they wish.

2) Clients can modify any product-related fields or delete a product from their child table and it does nothing to the master.

3) If a client adds a product to the child table — it adds the product to the master table with the flag — “do not show.” They can’t see it on the master table until a master system administrator enables “show.”

4) System admins can delete a record(product) from the master table, but this does not delete the product from the child table.

These specs seem to justify the need for parallel child tables. However, I'm thinking of potential problems relating to maintenance, especially when the master table structure changes. Any other ideas?"

setbasedisthetruepath
Used SQL Salesman

992 Posts

Posted - 2002-04-12 : 10:35:28
Replication!

setBasedIsTheTruepath
<O>
Go to Top of Page

Onamuji
Aged Yak Warrior

504 Posts

Posted - 2002-04-12 : 12:20:21
Just a thought:

create table clients
(
client_id int not null identity(1,1) primary key nonclustered,
user_name nvarchar(256) not null check (len(user_name) > 0) unique clustered,
password varbinary(256) not null
)

create table products
(
product_id int not null identity(1,1) primary key nonclustered,
client_id int null references clients(client_id),
name nvarcahr(256) not null check (len(name) > 0),
description nvarchar(1024) null,
unit_price money not null default 0.0000,
enabled bit not null default (0),
date_created datetime not null default current_timestamp
)

create table client_products
(
client_product_id int not null identity(1,1) primary key nonclustered,
client_id int not null references clients(client_id),
product_id int null,
name nvarchar(256) not null check (len(name) > 0),
description nvarchar(1024) null,
unit_price money not null default 0.0000
)

create trigger client_products_to_products on client_products for insert
begin
insert into products (client_id, name, description, unit_price, enabled)
select client_id,
name,
description,
unit_price,
0
from inserted
end
...

Added the trigger... haven't written a trigger in a while and I'm not sure if my syntax is 100% correct but the idea is there.

That's all you should need (plus/minus your own columns of course). I assume when you say:
quote:
1) Clients can add products to their table from the master table, but they don’t have to — they can add products manually if they wish.

That then they would select a product from the products table and it's name/description/unit_price would be inserted into the client_products table. Or they can create their own. I think this solves this criteria.

The next criteria is solved because there is no link between the products table and the client_products table.
quote:
2) Clients can modify any product-related fields or delete a product from their child table and it does nothing to the master.


The next problem is simple, the enabled bit is 0 thus just create a view that gets all ActiveProducts and have it filter for enabled = 1. The administator can change this to 1 once they approve the product.
quote:
3) If a client adds a product to the child table — it adds the product to the master table with the flag — “do not show.” They can’t see it on the master table until a master system administrator enables “show.”


This is fine as there is no references products(product_id) constraint in the client_products(product_id) table(column). The administrator can delete the item from products without having an effect on the client_products table.
quote:
System admins can delete a record(product) from the master table, but this does not delete the product from the child table.


This design is normalized (in my mind) not perfectly but each table has unique rows. No data is really duplicated anywhere.

Edited by - onamuji on 04/12/2002 12:25:34
Go to Top of Page
   

- Advertisement -