On 2013-11-11 22:24, ru...@yahoo.com wrote: > And your suggestion is not necessarily best either: why a 1:M > relationship? why not a M:M relationship? There may be duplicate > file downloads resulting in your suggestion being non-normalized.
You think that, after rejecting the addition of *one* new table for 1:M relationships, he'd go for adding *two* new tables for an N:M relationship? > But I think he is being perfectly reasonable in rejecting a > separate table if he feels it does not meet *his* needs (even if he > is wrong in your opinion.) However, the needs that he *describes* call for at least one more table, on pain of future problems, inter alia: - non-atomic updates - growth to an unknown number of files, exceeding the size of his one CHAR/VARCHAR field - difficulty querying which files were used (including the inability to easily summarize/group by file) - inability to maintain metadata for each file (a case for your N:M suggestion) Knowing these things and Nikos' historical inability to debug issues, it' worthwhile to get him to use a method that will result in less pain. Especially when you know from his description that his choices *WILL* cause him future pain. -tkc -- https://mail.python.org/mailman/listinfo/python-list
