Can Triggers Help Me out

Dear Experts,
I am storing the rates in pricelist table and these rates are used in
several tables.
Is is possible to create a trigger that will change rates in all the tables
wherever i have used the moment someone changes the rates in pricelist?
Thanks
Manish Sawjiani
Three Cheers to Technet for the Help!
Hi Manish
Triggers can help you, but u need to write
UPDATE <TABLE> ...
...
...
and so on, for all the tables that involved the price...
best Regards,
Chandra
http://chanduas.blogspot.com/
http://www.codecomments.com/gurus/default.asp?p=4223
"Manish Sawjiani" wrote:

> Dear Experts,
> I am storing the rates in pricelist table and these rates are used in
> several tables.
> Is is possible to create a trigger that will change rates in all the tables
> wherever i have used the moment someone changes the rates in pricelist?
> Thanks
> Manish Sawjiani
> --
> Three Cheers to Technet for the Help!
|||Manish Sawjiani wrote:
> Dear Experts,
> I am storing the rates in pricelist table and these rates are used in
> several tables.
> Is is possible to create a trigger that will change rates in all the
> tables wherever i have used the moment someone changes the rates in
> pricelist?
> Thanks
> Manish Sawjiani
Why not create a relationship between the rates and these other tables
if they need to be kept in sync with the main table? If that won't work,
you can use an update trigger and the inserted table to get a list of
all rows that were updated.
David Gugick
Imceda Software
www.imceda.com

Can Triggers Help Me out

Dear Experts,
I am storing the rates in pricelist table and these rates are used in
several tables.
Is is possible to create a trigger that will change rates in all the tables
wherever i have used the moment someone changes the rates in pricelist?
Thanks
Manish Sawjiani
--
Three Cheers to Technet for the Help!Hi Manish
Triggers can help you, but u need to write
UPDATE <TABLE> ...
..
..
and so on, for all the tables that involved the price...
best Regards,
Chandra
http://chanduas.blogspot.com/
http://www.developersdex.com/gurus/default.asp?p=4223
---
"Manish Sawjiani" wrote:
> Dear Experts,
> I am storing the rates in pricelist table and these rates are used in
> several tables.
> Is is possible to create a trigger that will change rates in all the tables
> wherever i have used the moment someone changes the rates in pricelist?
> Thanks
> Manish Sawjiani
> --
> Three Cheers to Technet for the Help!|||Manish Sawjiani wrote:
> Dear Experts,
> I am storing the rates in pricelist table and these rates are used in
> several tables.
> Is is possible to create a trigger that will change rates in all the
> tables wherever i have used the moment someone changes the rates in
> pricelist?
> Thanks
> Manish Sawjiani
Why not create a relationship between the rates and these other tables
if they need to be kept in sync with the main table? If that won't work,
you can use an update trigger and the inserted table to get a list of
all rows that were updated.
--
David Gugick
Imceda Software
www.imceda.comsql

Can these tables be combined?

I have currently created a design which uses three main tables for storing information related to financial actions. The two tables I wish to combine are described below. There is a third table after the OrderTransactions table which contains information about each step of a transaction.

This means that anytime I have to write a query to get information down at the transaction activity level (very frequently), I will have to always perform two joins. Would it be acceptable in this scenario to combine the Orders and OrderTransactions tables, and place a ParentOrderID field in there? A transaction would either have no parent, or would have to belong to a parent that does not have a parent.

This means that the information in the Orders table will be duplicated for each transaction. The data in the Orders table is more or less static after its initial insert. The data there is never updated, no matter which approach is used.

Either approach will work, I'm just looking to see what some of the people more knowledgeable than me think of the situation.

Orders:
Contains the core order information pertaining to all transactions

CREATE TABLE [Orders] (
[OrderID] [int] NOT NULL ,
[MerchantID] [int] NOT NULL ,
[CustomerID] [int] NOT NULL ,
[PaymentMethodID] [int] NOT NULL ,
[IsTestOrder] [bit] NOT NULL ,
CONSTRAINT [PK_Orders] PRIMARY KEY CLUSTERED
(
[OrderID]
) ON [PRIMARY]
)

Transactions:
Each order may have one or more transactions. All of the information in the Orders table is pertinent to a given transaction.

CREATE TABLE [OrderTransactions] (
[OrderID] [int] NOT NULL ,
[TransactionID] [int] NOT NULL ,
[TransactionTypeID] [int] NOT NULL ,
[CustomerIPAddress] [bigint] NOT NULL ,
[Description] [nvarchar] (250) NOT NULL ,
CONSTRAINT [PK_OrderTransactions] PRIMARY KEY CLUSTERED
(
[OrderID],
[SequenceID]
) ON [PRIMARY] ,
CONSTRAINT [FK_OrderTransactions_Orders] FOREIGN KEY
(
[OrderID]
) REFERENCES [Orders] (
[OrderID]
)
)I like recursive relationships. Just about every database I build has some element of recursion. But I wouldn't recommend it in this case.

Orders and order transactions are two different types of data. You want to combine them so you can avoid a join under some circumstances. But to check whether a given records represents a transaction you are going to need to use a join anyway, albeit a self-join ("A transaction would either have no parent, or would have to belong to a parent that does not have a parent"). You may save a bit on cacheing, but I doubt it.

Now, if a transaction could, under some business circumstances, represent a transaction, then you would have a good case for recursion. Or if an order could consist of a bundle of smaller orders. And I mean in your business model, not just that you COULD represent it this way in your schema.