July 6, 2004 at 5:18 pm
Hi all,
Starting a new contract shortly where I'll have some dealings with implementing views and Triggers. As I've been primarily a 'production-only' guy in the past, I'd be grateful for an idea of any compelling reasons why they're used instead of alternative SQL.
Cheers,
KS.
July 8, 2004 at 2:15 am
Hi KS,
Where I work we use views mostly for reporting purposes. We use Crystal Reports as the front end, and rather than using Crystal to define the query, we create a view (as in viewRPTTransactions), and then report on that directly. It also helps to keep the network traffic down (I'd think), and keep the query execution inside SQL where it belongs. Not being a total tech-head, I'm not really sure on this.
We also have views that provide joins of various tables where the data is commonly used together. They just make things easier, rather than having to recreate a whole bunch joins each time.
We don't use Triggers, primarily I think because they involve reimplementation for each table. AFAIK, you can't have a generic trigger, and then just attach it to a bunch of tables. We do use identities, and default values where the make sense.
HTH, pk
July 8, 2004 at 7:00 am
Triggers are a great way to enforce data rules that are difficult to enforce via constraints, unique indexes, or default values.
You can use stored procedures for this, as well. But, the table itself remains exposed outside of the stored procedure.
For example, on insert of a table A, some other data needs to be automatically generated and inserted into table B. A trigger will help you do this at the table level rather than at the stored procedure level. This way, you know in any case, data inserted into A guaratees data inserted into B.
Another may be that you can only insert data into table A when there exists a certain value in table B.
hope that helps.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply