Database design vs Application/UI design, pls help..

Question

Hi All,
I have to define a discoun that can be given on the combinations of the folllowing attributes : CustomerGroup, CustomerType, Customer, Region, District, Area, ProductGroup, ProductBrand, Product.
From the dba I get this table :
CREATE TABLE Promotions
(PromotionNo int NOT NULL,
PromotionName varchar(80) NOT NULL,
LimitAmount NUMBER(15,2) NOT NULL,
Status VARCHAR(15,2) NOT NULL,
Discount numeric(5,3) NOT NULL,
CustGroup int NULL,
CustType int NULL,
Customer int NULL,
Region int NULL,
District int NULL,
Area int NULL,
ProductGroup int NULL,
ProductBrand int NULL,
Product int NULL);
From the UI perspective, the requirement is to make data entry master-detail, with one master and three details like on this hierarchy :
PromotionMaster
(PromotionNo int,
PromotionName varchar(80),
LimitAmount NUMBER(15,2),
Status VARCHAR(15,2))
PromotionDetailByCustomer
(PromotionNo int ,
CustGroup int ,
CustType int ,
Customer int )
PromotionDetailByArea
(PromotionNo int ,
Region int ,
District int ,
Area int );
PromotionDetailByProduct
(PromotionNo int ,
ProductGroup int ,
ProductBrand int ,
Product int );
So here is the issue : To make the Promotions Table up to date, once the user press SAVE on the UI, the application must INSERT the following rows to the Promotions Table :
INSERT INTO Promotions
SELECT ..... FROM PromotionMaster JOIN
PromotionDetailByCustomer CROSS JOIN
PromotionDetailByArea CROSS JOIN
PromotionDetailByProduct
Is there any better approach than this ??
Thank you for your help,
xtanto

Answer 1

. Isn't it normalized ?In your previous post you said:
From the dba I get this table :
CREATE TABLE PromotionsThat table is not normalised.
Then I need a mechanism to make Cross Join from all details table to produce details
in PROMOTIONS table.Why? What purpose does that serve? If you already have actual tables representing
PromotionMaster, PromotionDetailByCustomer, PromotionDetailByArea and
PromotionDetailByProductthen the PROMOTIONS table is redundant. If you don't actually have those four tables in your database schema then that's bad. You should split the PROMOTIONS table into its constituent parts.
Why to make it easier for me to query which discounts a SalesOrder will get.If the PROMOTIONS table is intended to assist in this query then I think a table is the wrong answer. It is both an unnecessary waste of disk space and a A view would be better, although three views might be better still (one joining PromotionMaster with PromotionDetailByCustomer, one joining PromotionMaster with PromotionDetailByArea and one joining PromotionMaster with PromotionDetailByProduct). But I think the best of all would be a straight query on PromotionMaster with correlated sub-queries against PromotionDetailByCustomer, PromotionDetailByArea and PromotionDetailByProduct.
Still, without knowing more about the business rules and other sundry details (usage, table sizes, etc) it's difficult for me to be prescriptive.
Cheers, APC