我应该使用“RecordID”吗？作为列名？

发布于 2024-10-20 23:12:43 字数 561 浏览 2 评论 0原文

我正在创建一个包含五个部分的在线应用程序。每个部分都有自己的表格。我们将这些部分称为 SECTION1、SECTION2 等。将有一个名为 APPLICATIONS 的主表。该表中的第一列是 ApplicationID。

超快的服务器上只会有几千条记录，因此我想将注意力集中在表和关系的可读性上，而不是如果我在生病之前进行非规范化，我可以节省多少处理能力。

以下是我认为应该如何命名和构建表格的方式。您能确认这是最具可读性的方法吗？过去，我曾有效地做到这一点。但是，我想看看是否有一些简单的改进或想法可以集成。从一到十，这种表/列命名方法的可靠性如何？

APPLICATIONS - TABLE  
ApplicationID - pk  

SECTION1 - TABLE  
RecordID- int - pk  
ApplicationID - fk  
Answer1 - text  
Answer2 - text  

SECTION2 - TABLE  
RecordID- int - pk  
ApplicationID - fk  
Answer1 - text  
Answer2 - text

原文

I am creating an online application with five sections. Each section will have its own table. Let's call those sections SECTION1, SECTION2, etc. There will be a main table named APPLICATIONS. The first column in that table will be ApplicationID.

There will only be a few thousand records on super fast servers, so I want to focus my attention on table and relationship readability, not on how much processing power I might be able to save if I de-normalize till I am sick.

Here's how I am thinking I should name and structure the tables. Can you confirm this is the most readable method? In the past, I have done this effectively. But, I want to see if there are some easy improvements or ideas to integrate. On a scale of one to ten, how solid is this method of table/column naming?

APPLICATIONS - TABLE  
ApplicationID - pk  

SECTION1 - TABLE  
RecordID- int - pk  
ApplicationID - fk  
Answer1 - text  
Answer2 - text  

SECTION2 - TABLE  
RecordID- int - pk  
ApplicationID - fk  
Answer1 - text  
Answer2 - text

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

岁月如刀 2024-10-27 23:12:43

我总是将我的 id 列命名为 id，表名前缀足以知道我正在谈论的 id。

在另一个主题中，您的 SECTION 表似乎具有完全相同的结构，为什么不只使用一个带有 number 列或类似内容的表？

回复评论：通过

SECTION
id - pk
ApplicationID - fk
name

QUESTION
id - pk
text

SECTION_QUESTION
id - pk
SectionID  - fk
QuestionID - fk

ANSWER
id - pk
SectionQuestionID - fk
text

这种方式，您可以创建各种问题，甚至可以在各个部分之间共享一些问题。 SECTION_QUESTION 关联表映射问题和部分之间的关系。然后，您将答案存储到与 SECTION_QUESTION 关联的 ANSWER 中，而不是与 QUESTION 相关联，这样您就可以准确地知道答案是在哪个部分中做出的。

我希望我的提议是明确的。

I always name my id columns just id, the table name prefixed is enough to know that id I'm talking about.

In an other topic, your SECTION table seems to have the exact same structure, why not using only one table with a number column or something like this ?

in response to the comments :

SECTION
id - pk
ApplicationID - fk
name

QUESTION
id - pk
text

SECTION_QUESTION
id - pk
SectionID  - fk
QuestionID - fk

ANSWER
id - pk
SectionQuestionID - fk
text

This way you can create your various questions, even share some questions between sections. The SECTION_QUESTION association table map the relation between a question and a section. Then you store the answers into ANSWER which is associated to SECTION_QUESTION instead of QUESTION this way you can know exactly in which section the answer was made.

I hope my proposition is clear.

回复收藏 0 原文

尹雨沫 2024-10-27 23:12:43

我会采用这种结构：

Records - TABLE  
RecordID- int - pk  
SectionID int - fk
ApplicationID - fk  
Answer1 - text  
Answer2 - text  

Sections - TABLE
SectionId int - pk
SectionSequence int

您正在复制一个结构 - 如果这种结构发生变化（比如说您需要添加一列），您需要申请更改到多个表。 DRY 也适用于数据库。

I would go with this structure:

Records - TABLE  
RecordID- int - pk  
SectionID int - fk
ApplicationID - fk  
Answer1 - text  
Answer2 - text  

Sections - TABLE
SectionId int - pk
SectionSequence int

You are duplicating a structure - if this changes (say you need to add a column), you need to apply to change to several tables. DRY applies to databases too.

回复收藏 0 原文