I was sitting doing SQL triggers, but I was thinking they might be a bit taxing on a database, is there an alternative?
Depends on how you're using them. Depending on the DBMS triggers might be used internally anyway for various things, such as constraints, partitioning, or updateable views; its developers would be working to make them work well. Conversely, that means you might be trying to use triggers to reimplement a feature that's already present. Or you have a lot of stuff that needs to get done in a lot of places. This may be a symptom indicating a restructuring of the scheme is in order. If the schema is fine, then the goal you're trying to meet with the triggers might be consolidated into a stored procedure.
A trigger may be more efficient than having your application code do one or more additional queries, since the trigger is more or less compiled once then used many time (possibly depending on the DBMS?). That being said, I seem to only use them when trying to put a quick band-aid on something where it was easier to take care of the needed DB changes than changing a bunch of legacy (spaghetti) code.
Well the idea is to display lets call it "events" set on a particular date for example, a social function is scheduled to start at 9pm on 08/10/2017 and finish at 11pm, once the event is complete it would automatically delete at say 11:01pm for example
Hmm...I'd be more inclined to just limit what gets displayed in my SQL "where" clause, rather than deleting data, e.g.:
. . . WHERE event.end_time > NOW() . . .
Then you still have all the event data if you ever want to do anything else with it.
NogDog;11064161 wrote:Hmm...I'd be more inclined to just limit what gets displayed in my SQL "where" clause, rather than deleting data, e.g.: . . . WHERE event.end_time > NOW() . . . Then you still have all the event data if you ever want to do anything else with it.
Ah that would make more sense I guess
