在单独的数据库表中的人名结构 [英] Person name structure in separate database table

问题描述

我想知道何时何时不将数据结构拉入单独的数据库表，当它出现在几个表中。

I am wondering when and when not to pull a data structure into a separate database table when it appears in several tables.

我已经拉过了12属性地址结构因为我有几个不同的实体包含这种格式的单个地址。

I have pulled the 12 attribute address structure into a separate table because I have a couple of different entities containing a single address in this format.

但是我的3属性人名结构（给定，中间，姓）？

But how about my 3 attribute person name structure (given, middle, surname)?

这应该放在自己的表中，用外键引用所有包含名称的实体。公司表有一个联系人姓名，公民表有一个人名等。

Should this be put into its own table referenced with a foreign key for all the entities containing a name... e.g. the company table has a contact person name, the citizen table has a person name etc.

这些最好留在主表的属性还是应该提取？ / p>

Are these best left as attributes in the main tables or should they be extracted?

推荐答案

我通常将地址保存在Person表上，除非每个实体上有非常一致的地址，如果一个实体可以有任意数量的地址，或者地址需要在实体之间共享，或者如果它是一个大型企业产品，我知道我必须投资基础设施在所有地方，否则我会最终消除一切下来道路。

I would usually keep the address on the Person table, unless there was an unusual need for absolutely uniform addresses on each entity, or if an entity could have an arbitrary number of addresses, or if addresses need to be shared between entities, or if it was a large enterprise product where I know I have to invest in infrastructure all over the place or I will end up gutting everything down the road.

在一个单独的表中有你的地址很有趣，因为它是灵活的，但在一个小项目的上下文中缺乏上面提到的特殊需求，可能有点浪费。始终注意复杂性和灵活性之间的平衡。灵活性是重要的，但是有歧视...很容易投资太多了！

Having your addresses in a seperate table is interesting because it's flexible, but in the context of a small project lacking a special need like the ones mentioned above, it's probably a slight waste. Always be aware of the balance between complexity and flexibility. Flexibility is important, but be discriminating... It's easy to invest way too much there!

具体来说，我试验的时间（例如）对于诸如地址之类的东西我有一对一的关系，我最终将它们重构到表中，因为它引入了一堆头痛，包括更复杂的查询，处理地址不存在的情况等。更多的实体也增加了你的认知负荷 - - 它使项目更难思考。在我的情况下，这是一个不必要的成本，因为没有具体的需要，实际上，甚至没有灵活性的收益。

In concrete terms, the times that I experimented with (for instance) one-to-one relationships for things like addresses, I ended up refactoring them back into the table because it introduced a bunch of headaches including more complex queries, dealing with situations where the address does not exist, etc. More entities also increases your cognitive load -- it makes the project harder to think about. In my case, it was an unecessary cost because there was no concrete need and, in truth, not even a gain in flexibility.

因此，根据我的经验，我会尝试将地址保存在同一个表中，我会绝对保留名称 - 再次，除非是一个特殊的需要。

So, based on my experiences, I would "try" to keep the addresses in the same table, and I would definitely keep the names on them - again, unless there was a special need.

因此，对爱因斯坦进行释义，使它尽可能简单，不简单。但在短期内，实验。这是学习这些课程的最佳方式。

So to paraphrase Einstein, make it as simple as possible and no simpler. But in the short term, experiment. It's the best way to learn these lessons.

这篇关于在单独的数据库表中的人名结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！