Tag Info

New answers tagged

0

Assuming the system handles only a few actions per second and only millions of ids, either flavor of schema design should work well enough. I can think of no strong argument for, or against, splitting the confirmations off into a separate table -- performance, sparseness (or lack of) in the Confirmations table, 1:1 relationship, coding convenience, purging, ...


0

I'd probably go for 3 tables, department department alert employee and give the following relationships Employee to department department alert onto department department onto department (self join) Assuming your RDBMS can handle it, I'd then use a recursive CTE query to find every related department and join to alerts to get all of the alerts ...



Top 50 recent answers are included