问题
Someone asked a similar question before, but it wasn't answered. How to store value objects in a relational database?
Here is an example situation where my question comes into play. Let's say there is a 'users' table, and each user needs to have their location stored. Their location is essentially just 3 coordinates: x, y, z.
But, I'm not sure how I should be going about this. I could just add 3 integer fields to the 'user' row named 'x, y, z'.
Or, I could add a 'location' String field to the user row, and then simply serialize and deserialize whenever I fetch/save a user's location.
Or, I could create a 'locations' table, that has an auto-inc primary key id, that will be used as foreign key for the 'users' location database, which would have 4 fields: 'id', 'x', 'y', 'z'.
So, which one is best? Maybe there's an answer I'm not seeing that's better? Thanks.
回答1:
There generally isn't a "best" given that all scenarios are different, sometimes in subtle ways.
However, if you're looking for an overall "best practice" when designing something in general, I'd lean toward this:
Do the simplest thing possible, and only add complexity when needed.
To that end, I imagine that three integer columns in the Users table makes sense and is pretty simple. Do you need to serialize the data into a string? After all, the data itself isn't a string. It's a set of numeric values. That might make other things unnecessarily difficult, no? Does the data need to be in a separate table with its own identifier? After all, it's not really an entity in and of itself, but rather just a data point which describes a User.
Unless there's a compelling reason to do something more complex, keep it simple.
回答2:
In my opinion, normalized would be better.
Of course, there is no best way, as that depends on the workload (your queries that you will be running against these tables), the data itself, etc...
For example, will you be reading and updating x, y, and z a lot, that could make a difference if you have to parse them out of a string for every row going in and out, will you for example need a separate collection of locations, that way having those in a different table would help, etc...
回答3:
I would use your 3th option considering a User would need to store more data than just x,y,z. If not i would change the name of that table...
My reasons:
Readability of the database: ¿What represents x y z for a User? What represents x y z for a Location? The last one sounds more intuitive
If 100 Users are at the same location A, you just have to point those 100 users to that location A.
If you want to add more data to that location A (like address, lat lng, wheater...) just have to edit the table Location adding the columns and just edit one row (instead of 100).
You can use all the data stored on Location for other purposes. If you lately need to store also other instances like buildings, vehicles etc.. you have all the structure ready and even your current data is usable
Brieffing I find the last one much more readable, scalable and flexible than the other two. But it depends on the scope of your project I guess
来源：https://stackoverflow.com/questions/19661430/how-to-store-objects-in-a-relational-database