The additional module will be used by no more than 20 people on an intranet.
"People" is a fuzzy term when you're talking about legal applications. Supporting 20 lawyers is a lot different than supporting 1 lawyer, 4 paralegals, and 15 staff.
For legal cases new business rules are more like "everything is an
exception"
And that's one reason why. Within case management, certain kinds of things are simply deterministic. Timing of responses, deadlines for filing, things like that. But the rules that govern were written by lawyers for lawyers. Companies that build case management software have lawyers on staff to read the rules for procedure (which change over time) and to verify that their software complies with the rules.
Some of them have a lot of lawyers.
Other kinds of things are governed by whimsy. For example, some case management packages let users "template" their tasks. Entering something like "Deposition" on the calendar might also calendar a series of earlier tasks that have to be done to prepare for the deposition. Under the pressure of multiple, incompatible deadlines, parts of a task chain get dropped or given short shrift.
Now, to (finally) get to your question . . .
Decision tables in the database are a viable solution. In fact, decision tables constitute a database whether they're stored in Oracle or in application code. There are obvious trade offs to storing decision tables in application code.
But decision tables in the database are probably not a viable solution for you. The problem you have, if I understand you correctly, is that you think you might need to simplify the architecture to decision tables in order to eliminate (or at least to greatly reduce) the use of Microsoft Workflow. With just two of you and a minimal budget, success will be difficult at best.
I can suggest two things.
- Can you economically produce a prototype of a replacement system
built on decision tables?
- Can you use better hardware on the existing system?
Querying a column that can contain nulls is more complex than querying a column that cannot. So also is querying multiple tables more complex than querying one table. I wouldn't let the avoidance of null drive the normalization.
For example, you mentioned that all devices will eventually be disposed and get a disposal date. If there are no other columns in the Disposal table, then in my mind it makes more sense to put DisposalDate in the Device table. Other tables like Sanitize might make more sense as separate tables because there are multiple data points that will not apply to some Devices.
Check constraints are great and should be used when possible, but there will always be times when a procedure is necessary.
Best Answer
Two queries - two replies:
a) Placing business logic to database has strong defenders and strong opponents. Lot of arguments for/against are volatile and valid only for some configurations and environment. Some databases has not good capabilities for stored procedural programming, some companies has not good personal resources for programming in relative different environments. Some projects doesn't require really effective data processing and more valuable is simply monolithic deployment. There are a some arguments for placing business logic to database (only processes that are not INTERACTIVE!). You have to divide application to interactive (presentation) layer and non interactive layer (what is usually a best way, what you can do):
Generally I can say, a power of stored procedures is more significant in heterogenous environment and less in monolititic single application environment.
b) PostgreSQL has a CREATE OR REPLACE FUNCTION statement and data visibility based on snapshots - so update in production usually is not problem. You can update database dictionary (with functions) under transaction.