> Consider if there were a foreign key field on the posts table, named > "type" (or whatever), which indicated which "type" of object a row is. > "1" would presumably be "journal post". But then you could have "2" > be "market-place ad" (alluding to Denise's idea); it would show both > in the "market-place" and (optional user set preference) in the > poster's own journal. Or maybe 2 is "calender entry", where, if it's > well formed in calender entry format, it's picked up by the calender > module and shown as an event.
http://hg.dwscoalition.org/dw-free/file/1defc551af6c/bin/upgrading/update-db-general.pl Around line 929 you'll see the "talk2" table, which is used to (right now) hold comments. You'll notice the "nodetype" column, which is used to indicate what type of "thing" this is. I don't believe anything uses this column in a different way, but the functionality is certainly there to put things other than comments in this table. If I'm not mistaken, the original "log" table did similar (although it appears log2 does not). So; the idea has gotten some use in the LJ code, although it's not too wide. The problem I would expect comes from the traditional tradeoff between implementing something in the 'general' fashion and being very 'specific': speed and efficiency. Sure, you can write something that solves all sorts of problems, but it becomes quite impossible to tune it effectively. When you're talking about millions of users, efficiency matters. Also, the net cost of adding a new table to the database is minimal. InnoDB scales well to hundreds/thousands of tables, I have not seen/heard of limitations in the MySQL table handlers or MySQL itself around the number of tables. (Excepting MyISAM which requires fds from the kernel, and you have a limit on those, but it can be high...) > By format, something simple like the way post-by-email works to take > metadata. Using XMLish solutions the way Polls do is probably > overkill. > > Memories could be handled this way (if they aren't already). Possibly > also to-dos. Both memory and todo are going to die painfully, they need a re-build if they're going to be useful going forward. The systems are both so old and crufty that I'm not sure why they're still standing. > Theoretically so could Suggestions and Support requests -- thought > that actually has special architectural/performance concerns (as does > the marketplace and anything which aggregates content across multiple > journals). Yeah; that's the other big reason: special architectural things, as you mention. Sure, you could come up with a database format that's flexible enough to let you store anything you want, but the overhead goes up. > Because it's a foreign key field, as new systems were thought up, they > wouldn't need new db tables, just a new line on the "type" table -- > and a format protocol for within posts, which might be handled > entirely by the interface so the user doesn't have to learn it. > > People closer to the code than I would know if this is a terrible idea > or not. It's not a typical approach, so I thought I'd mention it. It's certainly not a terrible idea. It's actually a very modern approach to OO-ish database design. As mentioned above re: comments, it's already been put into the system, but nobody's ever figured out a great way to apply it without sacrificing performance - something LJ has never been able to do. Maybe DW will be a better position, but that remains to be seen once we figure out how much hardware/capacity we have and how close to the redline we run it. -- Mark Smith / xb95 [email protected] _______________________________________________ dw-discuss mailing list [email protected] http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
