问题
I'm creating clothing shop and therefore I'm creating gallery functionality which consists of 2 types: Product gallery and lookbook gallery. A product gallery is simply pictures of singular products and a lookbook gallery is pictures that contains multiple products.
So far i I have a simplified UML diagram somewhat like this
I'm not sure how to translate this into MySQL tables. I've tried and I came up with something like this
But it seems like overkill and smells funny to me. What would be best practice in my situation? Am i on the right track or am i way wrong?
回答1:
I don't know what "best practice" is on this, you could use a NO-SQL database or if you used a relational database you could just use 3 tables, Galleries, Pictures and Products.
A Gallery can contain many Pictures
A Picture can contain many Products.
The distinction between the types of galleries is just contained in an attribute.
回答2:
Firstly consider whether inheritance is the best way to implement the behavior you need. Generally it is best to prefer composition over inheritance. From your diagram I'd say that you really don't need inheritance at all to solve your problem.
If you do need to implement inheritance then there are a number of strategies you can use. It is a really good idea to look for an object relational mapper as a good one can make implementing the below strategies much easier. If your using .NET then NHibernate or Entity Framework are good options. For Java Hibernate is pretty good.
Table per class hierarchy
Here you'd create a single table for the entire class hierarchy. This makes most sense when the classes in the hierarchy all share many columns. You'd need to add a "discriminator" column so you could identify which subclass each row belongs to. In your example you'd have
- gallery
- picture
I'd say this strategy makes most sense for you as there don't appear to be many different columns between your sub-classes.
Table per subclass
In this example you'd create a table for each subclass. This makes most sense when the classes in the inheritance hierarchy don't share many common columns.
So you'd have tables like this:
- product_gallery
- logbook_galleries
- product_picture
- logbook_picture
Table per class
This is the strategy from your diagram. Like table per-subclass, This is useful when each of the sub-classes has different columns. The advantage over table-per-subclass is that it is easier to query the entire class hierarchy in one big join, the disadvantage is that you end up with lots of tables.
回答3:
That database schema looks like it's doomed to fail. The most important thing to do when defining a schema is to start with the nouns and verbs of your problem. Describe in words what your environment is like. What entities are there? How do the entities interact with one another? For example, "a gallery has pictures." That statement alone tells you there is an association between a gallery and pictures.
Once you come up with your noun-verb associations, you can begin illustrating entities such as "gallery" and "picture." Is there a one-to-one relationship among galleries and pictures, or is there one gallery to many pictures?
Think on these things, and check out some basic design tips here: http://msdn.microsoft.com/en-us/library/b42dwsa3(v=vs.71).aspx
来源：https://stackoverflow.com/questions/15306626/class-hierarchy-in-mysql