>>>>Hi,
>>>>
>>>>As I am redesigning my SQL Server database and see that I may have to "enforce" that all foreign key fields have only value of NULL when user does not assign a value. Since the database gets records from various applications (VFP, ASP.NET, iOS, etc.) I have to "enforce" this rule at the DB and therefore create a trigger for every field in every table. This means that I will have probably up to 200 triggers. Is this a normal/acceptable/good practice?
>>>>
>>>>TIA
>>>
>>>It is not a good choice.
>>>
>>>Uses NULL on vfp application.
>>
>>I understand about using NULL on VFP app. What are the reasons of using triggers as being not a good choice?
>
>The TRIGGERS quite slows the sql processing.
>
>Triggers are used in writing process,
>and on the writing the worst nightmare of those who uses relational databases are:
>the locks and, worse, the deadlocks.
>You can design the best in the history database,
>but if you run into too many locks, the experience of the users,
>It is very bad.
>
>More timing on writing, the greater the likelihood of having locks or deadlocks.
>
>We have to use it sparingly.
>
>If you can solve a problem before arriving in in sql, solve it before.
Thank you for the explanation.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham