The problem with your first example is the tri-link table. but I figured it's good to implement good practices whenever I can. In that sense, whatever solution I go with will probably only affect any developers that will need to maintain this system down the line. It's pretty much just for statistical reporting purposes. In terms of usage, the keywords will likely be used sparingly. It's an internal application with a small number of non-concurrent users, so I don't anticipate a high load. Should I go with this second structure? Am I missing any important concerns here? Also, if I do go with the second, what should I use as a non-generic name to replace "Object"? Instinctively, I feel like this isn't optimal and that I should have my taggable objects inherit from a common parent, and have that comment parent be tagged, which would give the following structure: BaseObjects Here's the structure I started out with: Reports However, I want to have just one set of keywords that gets applied to both Reports and Recommendations so that searching on keywords gives you Reports and Recommendations as results. I also have a separate table for Keywords (to implement tagging).
Each Report can have many Recommendations. The situation: I've got Reports in one table and Recommendations in another table. I'm trying to figure out the best way to design the database for an application I'll be coding. My background is more in web programming rather than database administration, so please correct me if I'm using the wrong terminology here.
0 kommentar(er)
