On 12/2/2014 8:50 AM, Peter Hunsberger wrote:
> I really think you need to give up on this particular line of
> reasoning. In particular, your examples make it clear you're aiming
> this at data exchange, not documents. As such, there is no "better" as
> far as flat or fat. Better is determined by the needs of the data
> exchange partners and can vary by use case, network bandwidth, target
> device and a host of other constraints that do not allow for the kind of
> generalizations that you are trying to make. Rather, at best these
> recommendations are useless and at best they will lead to broken designs
> that do not fit any needs at all.
+1. The thing is, you always have to ask "better? better for *what
purpose*?" In your zeal to promote what you see as "simple", you have
been consistently overlooking the purpose. And purposes vary.
Example: Microsoft Word binary files used to be (so I have read)
essentially the memory image of the data. Word could read the bytes
directly from the disk file into memory. That's why they loaded so
quickly, even in computers that were very slow in modern terms.
Isn't that the ultimate in efficiency and compactness? Yes, if you were
only using Microsoft Word. Yes, if you had to read the files off a slow
floppy disk, or over a slow network. No, if you wanted to be able to
use Word files with many different programs.
Also, normalizing data isn't really about "flattening" vs. "fattening".
It's about getting the dependencies identified clearly, and removing
redundancies. Depending on how you generate your interchange document,
when you have redundant data you may end up with inconsistencies,
especially after several rounds of revisions and extensions to the code.
What is the recipient supposed to do in the face of inconsistent data?
I think that everyone would agree that simplicity goes along with less
structure. I value simplicity. But, as has been attributed to
Einstein, "as simple as possible but no simpler".
Tom Passin
