I'm not sure there is a best practice for that, or at least I'm not aware of it.
Creating an object per comment and reflecting threads by structuring parent/child comments would be the default way, I think, and definitely some API exists to import that quite easily. But if you have a substantial number of those comments (going into tens or hundreds of thousands and above) and/or those comments are a key functionality and are expected to be very popular, then moving them into eZ Publish as objects may be risky - you'll end up with gigantic structure of objects of little singular importance. I such case I would think of moving this functionality outside of eZ Publish content model, into my own extension/database tables.
But it would be really great to hear someone who has actually dealt with this problem!
Thanks for your comments, Piotrek. Actually there are quite a few comments I want to import, about 60.000. What exactly will be the problem when I import them as eZ objects? Will that slow down eZ that much?
Threaded comments under a number of articles (or any other objects) should be fine - it's usually a problem when you have too many objects under one node. But I haven't dealt with an eZ site of that size from administrative side, so I wouldn't know for sure, but I expect the content-model tables to grow significantly. Sites with way more nodes are known to work fine, though, but you would have to ask others what's the cost.
