Indigestible is not a word commonly used with computer software. Perhaps it is time to add another definition to this adjective of the English language. As a database professional you will quickly see the value.
adjective
- (of food) difficult or impossible to digest
- too complex or awkward to read or understand easily.
“a turgid and indigestible book”I suggesting we might have a couple more definitions related to computer science.
- Data that does not follow the constraints defined in the storage implementation
- Data that is not normalized according to usage patterns
Not following constraints is probably the easiest definition of indigestible for you to understand. In order for data to be entered into a table it must conform to the data type, nullability, and any other check constraints defined in the table definition. Foreign keys must also be obeyed in order for data to be entered into a table. If the data does not conform, then inserts or updates fail, and it is therefore Indigestible.
Following the concepts presented in the second definition above, about reading a book, the example states that something is indigestible when it is too complicated to understand. I have seen, and created, database structures that have a lot of complexity. A good example would be when you have the ability to override a feature at different levels within a hierarchy.
A good example would be a database with a hierarchy of Region, State, City, Store. The application allows you to filter on features that may be assigned to any level in the hierarchy. The overrides have to be honored in reverse order of the hierarchy, so that any override is implemented at the lowest level where it is set. Let’s say you can override the language for any or all of these levels of the hierarchy. You query would look something like
SELECT
COALESCE(
StoreOptions.LanguageId
, CityOptions.LanguageId
, StateOptions.LanguageId
, RegionOptions.LanguageId
, SystemOptions.LanguageId) AS LanguageId
FROM Store
LEFT JOIN Options StoreOptions ON Store.StoreId = StoreOptions.HierarchyId
LEFT JOIN Options CityOptions ON Store.CityId = CityOptions.HierarchyId
LEFT JOIN Options StateOptions ON Store.StateId = StateOptions.HierarchyId
LEFT JOIN Options RegionOptions ON Store.RegionId = RegionOptions.HierarchyId
JOIN Options SystemOptions ON SystemOptions.HierarchyId = 1
This example is not unusual. A Hierarchy is a very useful data structure to have in many databases. However, a query such as this becomes more convoluted as you find yourself having to make decisions by order of precedence. There is nothing wrong with it, if that is what your business requires. The question you have to ask yourself is, “Do the requirements warrant the complexity of this design?” If not, then perhaps this design may be labeled indigestible, and simplified for all concerned.
Cheers,
Ben