[eluser]jedd[/eluser]
Reading back, I was perhaps a tad (but just a tad, mind) harsh. In my defence, I was frustrated by the OP's intimation that they knew they were doing something silly (as per the comment of theirs that I quoted). I would have been far more diplomatic had it not been obvious they were wantonly being obtuse.
Chad - thanks for your comments.
[quote author="Chad Fulton" date="1249427116"]
In my view, the idea that there ought to be a "generic" database table to hold both sorts of comments is a bad practice, since there is no semantic reason why comments regarding magazines and comments regarding books ought to be the same, or stored in the same table.[/quote]
I'm not sure what
semantic reason means in this context. But more tellingly, can you describe the difference between
'... both sorts of comments' as you see it? From my reading of the original post - and I think the words 'exactly the same' cropped up there - there's no algorithmic way of differentiating between the two comment types. Or, if you prefer, they are
semantically aligned.
If that's the case, we have a square peg / square hole arrangement.
If, OTOH, there is a discernible difference between magazine comments and book comments, then bring on the extra table.
Quote:For one thing, it needlessly complicates growth down the road. What if there are comment fields specific to books that don't apply to magazines, or vice versa?
I'm confused by this. In my (imagined) schema, there would be one table for the publication (id , type char(1), title char(x)) and one that described comments (id, publication_id, comment char(x)) - so multiple comments can be tied to a single book or magazine, and there is no problem about comments that might be specific to a book.
Quote:For me, the clear answer in this situation would be creating a Comment model, and extending it with BookComment and MagazineComment (as the original comment suggested). The whole point of extensions is just for this sort of problem: how to deal with two things that share common basic elements but differ in their specific implementations.
Yes, I wholeheartedly concur - this is the idea behind OO, though perhaps not OO in the sense that PHP, or more importantly in this case, CI implements it.
In this particular instance there appears to be no discernible difference between the attributes of a book and the attributes of a magazine. Arbitrarily pretending there are differences - especially given the only reasons given so far were for 'performance and size' considerations - is, at best, an inelegant approach. To me it would be like having a separate table again for any books written by a philosopher with an S in their name.
Quote:Although if they truly are exactly the same, and there is no chance they will deviate, then I agree that it might just be easier to combine them into a single one.
If only you'd mentioned that earlier ...
