To whoever hacked into my Database

Tim Chase python.list at
Tue Nov 12 12:30:05 CET 2013

On 2013-11-11 22:24, rurpy at 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

> 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
- 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

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.


More information about the Python-list mailing list