how much do you have?
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Zero. Though I may have written one about ten years ago. Only as a convenience for debugging. It was not vital to the system.
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
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
-
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.
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
:sigh: 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
-
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.
-
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)
-
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.
-
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...
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
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!
-
I found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
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 found we use SQL triggers a bit too much... 336 triggers on 1450 tables... (~23%)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
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.
