问题
Suppose I'm writing software for party-planners to use. This is what my current database schema looks like:
Parties ( PartyId, ClientId, DateTime )
Tents ( PartyId, TentDetails... )
Clowns ( PartyId, ClownDetails... )
SecurityAgentAssignment ( PartyId, AgentId, fromTime, untilTime )
So as you can see, a Party can have multiple tents, clowns, and security agents assigned to it.
Now, the party planner often plans parties that are of the same type: most have one tent, one clown, and no security; but there's also another common type of party that has three tents, no clowns, and three security agents attending the party. They'd like to be able to store "presets" (also known as "party packages" or "party templates") that when selected would add the necessary Tent, Clown, and Security rows in the database. The party can still be customised as usual, of course, this is just a means of minimizing initial data entry.
Now the problem is, how would I implement this?
The most straight-forward way is to make copies of the Tents, Clowns, and SecurityAgentAssignment tables and add a new Packages table, like below:
Packages ( PackageId, Name )
Package_Tents ( PackageId, TentDetails... )
Package_Clowns ( PackageId, ClownDetails... )
Package_Security ( PackageId, AgentId )
The biz logic then has to create the Tent row from the Package_Tent rows, it can't be done by an INSERT INTO SELECT FROM statement because the two schemas differ (Package_Security lacks the fromTime and untilTime fields, for example).
This approach is simple and works, however it has a few problems:
- It means duplicating a load of tables just for the Package system. This is how projects get table-bloat.
- It introduces an extra layer of maintenance: if I modify the original tables I then have to modify these too.
- It just seems "wrong" somehow.
A second approach means using the existing tables, but adding a single new table like so:
Packages ( PackageId, Name, PartyId )
This Packages table links to an existing Party row (and its associated Tents, Clowns and Security rows). The Party it links to is non-existant (or rather, its details don't matter), it becomes a template for new parties where it's just a matter of duplicating rows in a single table rather than creating rows in a new table from another table. This approach also has the advantage of allowing the user to use the existing GUI to modify Packages as prototype parties rather than having separate GUI tools/areas.
However it suffers from "impurity": how now a Party's state as a "party" instead of a "party template" is dependent on whether or not its a foreign-key in the Packages table. It also means that there will be invalid or meaningless data that exists (for example, it doesn't make sense to have the fromTime and untilTime for Security in a party template).
Does StackOverflow favour one approach over the other, or is there a third way out?
回答1:
It definitely makes sense to go with the second approach. Every design has its pros and cons but the advantages of the second approach (reusing the schema and the GUI) far outweigh any minor concerns.
Personally, I don't consider any of the issues you mentioned to be "impurities" in the schema, rather they are business constraints that need to be made explicit in the application, for example:
- if editing a party template, ignore
fromTimeanduntilTime, and hide these in the GUI - if editing a regular party, make sure that
fromTimeanduntilTimeare valid
回答2:
The way I see it, templates are just that, templates: presets. You could store the preset values as xml. Leaves you wide range to change the template without breaking table structure and only the app code needs to deal with parsing and translating the xml at runtime. The only drawback here is the xml might become unmanageable if the template grows too large. But for small-medium size use and an effective DAO/ORM layer, your config will do well with
Party_Template(template_id,template_title,template_desc)
来源：https://stackoverflow.com/questions/12292066/extending-an-application-design-automatically-generating-data-items-from-templ