|
Kornfeld Eliyahu Peter wrote: (~23%)
We got you beat. 247 triggers on 741 tables, exactly 1/3, although not intentional.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I avoid them as triggers too easily lend themselves to database-vendor specific code.
Installing Signature...
Do not switch off your computer.
|
|
|
|
|
My former bosses have about 10 - 15 triggers on each and every table, some of them thousands of lines long. A nightmare.
Especially after that experience: 0.0 triggers per table and not a single trigger more.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
That sounds awful... Our triggers are short (sometimes 2-3 triggers on the same event, just because they all do something else)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The major part of the application logic took place in those triggers. Guess why I run out of job interviews when I hear 'Access' or ' Former Acess project that has ben ported to xxx'.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Hey! I'm (still) working on an Access project ported to SQL Server. Don't knock it if you haven't tried it!
Triggers are useful, but to embed business logic? Then even I would run away...
8)
|
|
|
|
|
It's the 'We don't need any architecture or documentation, and you are a fool for asking.' mentality that I don't like. They can keep on doing their stuff as long as they like (or until their customers finally have enough), but I will not work like that again.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Oh, indeed! Fortunately this project was written originally (entirely in Access) by someone who actually had a clue, and the 'owner' who understands the business (and is also a dev) has worked on it - so I have been able to gradually document the entire setup, what things represent and do etc.
Whilst it's still very much a work in progress, I've been able to add all sorts of functionality, but I've discovered nearly 60 GOTCHAs (so far!) when moving from Jet to SQL - documented hereabouts somewhere. The trickiest new feature was CRM functionality as the data had to be imported from another (commercial) system where ALL information (used in tens, if hundreds) of different views was all stored in ONE huge SQL table and extracted by the most complicated series of inner joins and table aliases that I have ever seen. The person who wrote that must have been on acid! "Normalisation - never heard of it!" Definitely write only code...
|
|
|
|
|
Sounds like a bunch of trigger happy bosses 
... such stuff as dreams are made on
|
|
|
|
|
CodeWraith wrote: My former bosses
Database guys in charge of application development? Sounds like it to me.
|
|
|
|
|
Even worse. Access guys in charge. I must have offended him when I looked at that stuff and asked him what this particular form of insanity is called.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Lotta time I see...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Working on a review of the DB design to suggest improvements...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
all the best
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I've used 2 in my entire 32 years of doing this crap.
|
|
|
|
|
|
Zero.
Though I may have written one about ten years ago. Only as a convenience for debugging. It was not vital to the system.
|
|
|
|
|
Surely that would affect performance to have that many? Most DBs I've worked on tend to not have more than a few tops.
Jeremy Falcon
|
|
|
|
|
 I hate triggers spit
Development - 0 triggers
UAT and Production 3 triggers on each of the master tables.
I have a script that uses a configuration table to create and remove audit triggers on selected tables for each database. As we have approx 15 databases, any 3 of which will be deployed to production in any month this script is a life saver.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
17 triggers on 93 tables, but not evenly spread out so don't think percentage makes sense.
Almost exclusively used to send mails so fairly harmless though. 
|
|
|
|
|
Database has 147 tables and we have 145 triggers. It is a vendor independent change tracking mechanism that we developed so that we could make it portable.
|
|
|
|
|
Triggers have their place. Like Global variables, and the rarely used GOTO.
growing up in Oracle, every table with an ID column got a sequence, and a trigger.
A Concept that bothered me (vs the simplicity of auto-increment), but I was grateful for before the "OUTPUT Inserted.ID" could accurately tell me the identity of an inserted row!
We used them to log changes across multiple applications (web and various clients), and those logs were used to restore data that was accidentally "lost" due to human error.
But when I have the OPTION of limiting access to a single application... You don't have to have them, and you really need to make sure you are not just being lazy... Or making a system overly complicated!
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: I found we use SQL triggers a bit too much...
336 triggers on 1450 tables... (~23%)
I never kept track because my coding responsibilities weren't close to the database but when I did have to work there I discovered way too much business logic in our stored-procedures and triggers. So much that it made diagnosing bugs extremely difficult. One of the stored procedures was a complex query that was so deep that it could take days just to figure out what the desired result set would be ... of course it was heavily commented (NOT!). I can't stand it when someone seems to intentionally write obscure, un-maintainable code.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
I do not use them. I understand them. I understood their place back when databases often housed business logic in a client-server environment.
But - IMHO informed by experience - applications are scalable and reliable when databases are limited to CRUD operations, and business logic and whatever one once used triggers for, is placed in the compiled code in middleware.
Yes, it is easier to update a trigger, SP, view, or UDF since apps do not have to be updated. But as most can attest, the DB complexity mushrooms and performance is hurt.
Intelligent app architecture compensates for much of that.
My advice is to keep the DB to a CRUD machine, and leave the logic to the compiled code.
|
|
|
|
|
When I go to the CP home page the icon (favicon) in the Chrome tab is the twitter bird. Anyone else?
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
