For economical reasons the output is stored as text (CLOB) in database, violating the principles of rational relational database usage.
The alternatives were:
- a dedicated table (entity) that would need to be changed everytime the other system changed
- table with attributes: form_id | field_name | field_value
- dynamic class with .toXML_CLOB() and .readFromXML_CLOB() methods to parse the XML
The first idea was rejected because it was unpractical - changes to XML output would break the integration. The changes to forms system are unpredictable and the solution was rightly rejected.
The second idea was used in some systems previously in our company and served us well. I've maintained such systems for 4 years. I liked possibility of mass update of fields in case of :
- application needing different format of value
- app ceasing to accept some values/value ranges
The third idea is riddiculous in static java world.
The rationale
The reason simple text storage was choosen was that very little bugs or updates were expected. This turned out to be true, because of enormous experience of team making this decission. Bear in mind hovewer, that it might have turned otherwise.
The type of decission is beeing called 'engeeneering 95% decission', which means that is is solves 95% of requirements/problems.
The type of decission is beeing called 'engeeneering 95% decission', which means that is is solves 95% of requirements/problems.
The misscalculation
But was it truely the effective decission or unwise bow to the budget? Please notice, that the implementation cost of field_name | field_value table is not very much higher than CLOB. I'd say 2 or 3 times more work (max 40 hours more). And we're talking about two year project in team of 15 people. And we're talking about integration.
Integration is something that can't be easly changed once it starts being used.
The hidden cost are those lost opportunities.
Integration is something that can't be easly changed once it starts being used.
The hidden cost
What was not taken under consideration are the lost opportunities of good software. The value and stability of well written app is stressed across many books and lectures in the field. Yet it gets forgotten so often.
Let's explore the opportunities of good, simple implementation field_name | field_value. Those are things easly done with this implementation and very hard to be done upon XML CLOB:
Let's explore the opportunities of good, simple implementation field_name | field_value. Those are things easly done with this implementation and very hard to be done upon XML CLOB:
- mass update of date format
- when a field may no longer be empty, a mass update of default value is easly done
- analysys of values in specified field is easly deliverable
- one may search for a form with specified e-mail
- easy duplicate values (e-mails to be precise) detection and rising alerts
- additional business-critical validation of user-entered values is possible. Some data is unavailable for forms system but is available in frontend system. Some critical assumptions could be tested (and re-tested) after form has been submitted.
- any request to alter or analyse forms data would be reasonably priced. Reasonable pricing of simple operations is good. Prohibitive prices for simple things are very, very bad for business relations.
- alternate ways to deliver the forms data to the system would be easly possible - the frontend system would have a possibility to become some kind of center of processing data. Good for business, right?
Summary
- Good implementation delivers higher value to customer who paid for the system.
- Good implementation allows better business-to-business relations
- Good implementation allows system to grow and become a importand bond between business partners
The hidden cost are those lost opportunities.
