Mysql:枚举混乱

发布于 2024-08-23 06:35:28 字数 1099 浏览 8 评论 0原文

我有一个员工表,员工有兴趣,所以表可以这样设计:

create table emp(
 id int(10) not null auto_increment,
 name varchar(30),
 interest varchar(50),
 primary key(id)
);

或者这样:

create table emp(
 id int(10) not null auto_increment,
 name varchar(30),
 interest enum('football','basketball','music','table tennis','volleyball'),
 primary key(id)
);

兴趣数量可以是50左右。

我应该如何设计表?我应该使用枚举还是其他?

编辑:

感谢您的回复。

假设一个人可以是先生、女士或女士。

我用 PHP 制作了一个下拉列表。

<select name="role">
<option value="Mr.">Mr.</option>
<option value="Ms">Ms</option>
<option value="Madame">Madame</option>
</select>

对于数据库部分,我可以这样做:

create table emp(
    id int(10) not null auto_increment,
    name varchar(30),
    role varchar(50),
    primary key(id)
);

或这样:

create table emp(
    id int(10) not null auto_increment,
    name varchar(30),
    role enum('Mr.','Ms.','Madame'),
    primary key(id)
);

在这种情况下,哪个更好?

I have an employee table, employee has interests, so the table can be designed like this:

create table emp(
 id int(10) not null auto_increment,
 name varchar(30),
 interest varchar(50),
 primary key(id)
);

or this:

create table emp(
 id int(10) not null auto_increment,
 name varchar(30),
 interest enum('football','basketball','music','table tennis','volleyball'),
 primary key(id)
);

The number of interests can be about 50.

How should i design the table? Should i use enum or others ?

Edit:

Thanks for your reponse.

Assume that a person can be a Mr. or Madame or Ms.

I make a drop down list in PHP.

<select name="role">
<option value="Mr.">Mr.</option>
<option value="Ms">Ms</option>
<option value="Madame">Madame</option>
</select>

And for the DB part, I can do this:

create table emp(
    id int(10) not null auto_increment,
    name varchar(30),
    role varchar(50),
    primary key(id)
);

or this:

create table emp(
    id int(10) not null auto_increment,
    name varchar(30),
    role enum('Mr.','Ms.','Madame'),
    primary key(id)
);

In this context, which is better?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

情魔剑神 2024-08-30 06:35:29

还有第三种选择,创建一个附加表来保存利息值。

兴趣

  • interest_id、int、主键
  • interest_value、string/varchar、唯一约束(阻止重复)

多对多关系?


但是,如果您想支持具有多种兴趣的员工,您将需要第三个表。这是多对多关系 - 第三个表位于 EMPLOYEES 和 INTERESTS 表之间,并且与这两个表都有外键关系。

EMPLOYEE_INTERESTS

  • employee_id,主键,EMPLOYEES.id 的外键
  • interest_id,主键,INTERESTS.interest_id 的外键

一对多关系?


如果一条 EMPLOYEES 记录只能有一个 INTEREST,那么您只需更新 EMPLOYEES.interest 列即可与 INTERESTS 表建立外键关系。

EMPLOYEES

  • interest_id,主键,INTERESTS.interest_id 的外键

There's a third option, creating an additional table for holding the interest values.

INTERESTS

  • interest_id, int, primary key
  • interest_value, string/varchar, unique constraint (to stop duplicates)

Many-to-Many Relationship?


However, if you want to support an employee having multiple interests you'll need a third table. This is a many-to-many relationship - the third table would sit between the EMPLOYEES and INTERESTS tables, and have foreign key relationships with both.

EMPLOYEE_INTERESTS

  • employee_id, primary key, foreign key to EMPLOYEES.id
  • interest_id, primary key, foreign key to INTERESTS.interest_id

One-to-Many Relationship?


If an EMPLOYEES record can only ever have one INTEREST, then you only need to update the EMPLOYEES.interest column to have a foreign key relationship with the INTERESTS table.

EMPLOYEES

  • interest_id, primary key, foreign key to INTERESTS.interest_id
昇り龍 2024-08-30 06:35:29

假设一名员工可以有多种兴趣,您实际上应该制作 3 张表。 (您当前的设计将每个员工限制为 1 个兴趣。)像这样:

Employee (emp)
-------
id
name

Interest
-------
id
description

Employee_Interest
--------
employeeID
interestID

关于编辑,我想说枚举是您的 2 个示例中更好的一个,因为它将您限制为预定的允许值。但很多人会认为你应该创建一个查找表(带有 ID 和描述的角色),即使如此

You should really make 3 tables, assuming that an employee can have multiple interests. (Your current design limits each employee to 1 interest.) Something like this:

Employee (emp)
-------
id
name

Interest
-------
id
description

Employee_Interest
--------
employeeID
interestID

Regarding the edit, I'd say the enum is the better of your 2 examples as it limits you to predetermined allowable values. But many would argue that you should make a lookup table (Role with id and description) even for that

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文