To whoever hacked into my Database

[Tim Chase]

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