DRY -- "ThirdNormalForm is the analogous principle for data." (?)
I recently bumped into a particularly austere (desiccated?) proponent of DRY/Don't Repeat Yourself. My Subject quote is from the WikiWikiWeb discussion 'External link'ed from that wikip page. I get a drift that Real Programmers are DRY; tables relations with a Foreign Key are intrinsically suspect/wimpy for 'repeating' a value appearing elsewhere as Primary Key.
- That WikiWeb discussion has a few mentions of Normalisation theory, but no acknowledgment of BCNF, 4NF or higher.
- The mention of source code -- and of application configuration files in general, which is what I recently bumped into -- makes 'flat'
tablesrelations theory less applicable: config is typically held in directories which are hierarchical. If your.yamlis in a directoryfoo, does calling itfoo.yamlamount to repeating yourself? If the.yamlincludes text literalsfoo "foo"is that more repeating? If you clone directoryfooto directorybar, you then have to go through the contents overwriting all appearances offoo, so I guess you were repeating yourself. - " a function signature is duplicated at the function call site and the function definition site. " "in CeePlusPlus the interface and implementation for a class are typically specified in separate files, duplicating knowledge. ... duplication between .c and .h files is annoying"
These seem parallels to Primary Key vs Foreign Key references.
If Normal Form analysis doesn't give guidance as to what counts as repeating, is there some more abstract analysis framework to cover directories[**]/hierarchies/trees?
[**] I still recall fondly the System 38/AS400's refusal to support hierarchical directories. "Single-level store" applied for both memory/disk addressing and databases and applications. Life was simpler.
IMO this is just stirring the pot. There is nothing here.
DRY says you should not assert the same fact twice. If the fact is a function to compute a value, it should not be repeated. Ditto if it's the value of a data item. Dry is not violated by multiple references to that function, or to that data item. FKs that reference a PK do not inherently violate DRY.
Non-normalised relations may violate DRY, which normalisation may alleviate.
Quote from AntC on October 7, 2025, 2:31 amIf Normal Form analysis doesn't give guidance as to what counts as repeating, is there some more abstract analysis framework to cover directories[**]/hierarchies/trees?
I don't think Normal Form analysis is entirely relevant for the dryness, although I'm quite sure it corresponds to cleaner/better/more orthogonal code in other ways.
I'd say the master programmer's perception of DRY is more relatable to the predicate and set logic so that each fact or logic rule is represented exactly once.
The novice programmer will often get confused by repetition on the implementation level, where exactly the same implementation could be duplicated for different logical purposes, which is NOT repetition.
DRY is a spectrum not a boolean, and a desirable inclination rather than an absolute.
Yes, a foreign key value or reference to a function or variable is repeating yourself, but less so than storing the same configuration value in multiple places or the same fact in multiple tables/relvars. Eliminating all repetition may -- depending on circumstances -- be worse than accepting some.
Evaluate tradeoffs.
I disagree. Asserting a fact twice is repeating yourself. Asserting it once and referring to it once is not (the fact and the reference are different things). The DRY principle advises against multiple assertions, but not multiple references to a single assertion. Do you have any authority that would say otherwise?
Multiple references to a single fact are the subject of a quite different issue: dependencies. The parallel of DRY is: Minimise Dependencies. If the fact asserted is wrong, every reference to it will be wrong too.
Quote from dandl on October 7, 2025, 11:32 pmI disagree. Asserting a fact twice is repeating yourself. Asserting it once and referring to it once is not (the fact and the reference are different things). The DRY principle advises against multiple assertions, but not multiple references to a single assertion. Do you have any authority that would say otherwise?
One example of asserting the same fact multiple times is in microservice architecture, where some duplication of -- for example -- configuration or even database contents (the same table may be manually duplicated in multiple services, each with their own local database) because the cost of dependencies are considered worse than the cost of managing duplication.
Another example is denormalisation in analytics schemas to maximise performance when the cost of joins is prohibitive.
Another -- and this may be the controversial one -- is use of foreign keys on data values instead of immutable generated keys.
Do you have any authority that would say otherwise?
Me. I'm old enough, have been doing this long enough, and am ornery and arrogant enough, to claim authority on everything.