On Sun, Nov 3, 2013 at 11:16 PM, Roy Smith <r...@panix.com> wrote: > The limitation, of course, is that the data is opaque as far as the > database goes; you can't do queries against it. But, if all you need to > do is store the list and be able to retrieve it, it's a perfectly > reasonable thing to do, and a lot more efficient than doing a join on a > secondary table.
Yeah, that can be an effective way to store complex data - especially if the nesting level isn't fixed. (Normalization can handle a single-level list, but it's a lot messier for handling lists of lists, for instance.) I still think that the OP's task would be best suited to a separate table (one table of visitors, another of downloads, where the Downloads table has a foreign key to Visitors), but I'm reminded of XKCD 1027: the thing standing in the way of his code is that the person coding it... is him. And of course, this is all without getting into the non-code aspects of this proposal - as have been mentioned several times, like EU regulations on retaining this level of data. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
