组织 table 避免冗余
Organize table avoiding redundancy
我正在尝试创建一个数据库来管理 autobus 数据
CREATE TABLE Company(
Company_Name VARCHAR(12),
Tel INT,
PRIMARY KEY(Company_Name)
);
CREATE TABLE Line(
ID_Line VARCHAR(3),
NCompany_Name VARCHAR(12),
Desc TEXT,
PRIMARY KEY(ID_Line, Company_Name),
FOREIGN KEY (Company_Name) REFERENCES Company(Company_Name)
);
CREATE TABLE Stop(
ID_Stop VARCHAR(3),
geoLat FLOAT(10,6),
geoLong FLOAT(10,6),
PRIMARY KEY(ID_Stop)
);
CREATE TABLE Make(
ID_Stop VARCHAR(3),
ID_Line VARCHAR(3),
Hour TIME,
PRIMARY KEY(ID_Stop,ID_Line),
FOREIGN KEY (ID_Stop) REFERENCES Stop(ID_Stop),
FOREIGN KEY (ID_Line) REFERENCES Line(ID_Line)
);
问题是一辆公共汽车在不同时间在同一个站点停了好几次,我该如何存储这些信息以避免冗余?
例如:
Id_Line = 1
ID_Stop = 1
Hour = 4:50
比
Id_Line = 1
ID_Stop = 1
Hour = 5:20
但这不可能,我想添加另一个名为 ID 的字段(自动增量),但我不知道这是否是最佳解决方案。你有什么建议?
这是我想要的设计
CREATE TABLE Company(
CompanyID SMALLINT IDENTITY(1,1),
CompanyName NVARCHAR(12),
Tel INT,
PRIMARY KEY(CompanyID)
);
CREATE TABLE Line(
LineID INT IDENTITY(1,1),
Code CHAR(3),
CompanyID SMALLINT,
Desc NVARCHAR(MAX),
PRIMARY KEY(LineID),
);
CREATE TABLE [Stop](
StopID INT IDENTITY(1,1),
geoLat NUMERIC(9,6),
geoLong NUMERIC(9,6),
PRIMARY KEY(StopID)
);
CREATE TABLE Make(
MakeID INT IDENTITY(1,1),
StopID INT,
LineID INT,
[Hour] SMALLINT,
PRIMARY KEY(MakeID),
);
我所做的更改以及原因:
- 转换为使用标识列,因为 INT 小于 VARCHAR(3);这一次又一次地在索引上付出代价。
- 已将 VARCHAR 转换为 NVARCHAR。现在增加了国际潜力。
- Desc 现在是 NVARCHAR(MAX),因为 TEXT 是已弃用的数据类型,不应使用。您真的需要那么大的字段来进行描述吗?如果没有,缩小它。
- 主键更新为标识列
- 小时从 TIME 格式更改为 SMALLINT,因为它是一种较小的数据类型,我怀疑您需要估计公交车到达时间以外的时间。 (1720=下午 5:20)
- 您的坐标已降为数字 (9,6)。这应该以尽可能小的数据类型提供您所需的精度。
至于冗余数据,不要被炒作所迷惑。正常化有时间和地点,但不是每次都如此。添加另一个 table 以消除到达时间的冗余实际上会导致您的数据库更大,而不是更小。
您对谓词“[ID_Line] 在时间 [Hour] 停在 [Id_Stop] 感兴趣”。 Table Make as defined 将保留使之成立的行。它唯一的候选键(因此是主键)是 (ID_Stop,ID_Line,Hour) 因为没有其他列子集是唯一的。您的图表应包括小时(根据您使用的任何图表约定)。对于 (ID_Stop,ID_Line) 对(它不会识别 Make 的行,而是曾经停止过的行停止对)或 (ID_Stop,ID_Line,时)三胞胎.
The problem is that a bus stops several times at the same stop in
different hours, how could I store this information avoiding
redundancy?
没有这个问题。无论是否存在 "redundancy",子行都可以在 table 中出现多次。 (无论你认为那意味着什么。虽然可以用 id 加上另一个 table 替换多次出现的 subrows,然后需要更多 joins 相同的查询结果。见 .)
我正在尝试创建一个数据库来管理 autobus 数据
CREATE TABLE Company(
Company_Name VARCHAR(12),
Tel INT,
PRIMARY KEY(Company_Name)
);
CREATE TABLE Line(
ID_Line VARCHAR(3),
NCompany_Name VARCHAR(12),
Desc TEXT,
PRIMARY KEY(ID_Line, Company_Name),
FOREIGN KEY (Company_Name) REFERENCES Company(Company_Name)
);
CREATE TABLE Stop(
ID_Stop VARCHAR(3),
geoLat FLOAT(10,6),
geoLong FLOAT(10,6),
PRIMARY KEY(ID_Stop)
);
CREATE TABLE Make(
ID_Stop VARCHAR(3),
ID_Line VARCHAR(3),
Hour TIME,
PRIMARY KEY(ID_Stop,ID_Line),
FOREIGN KEY (ID_Stop) REFERENCES Stop(ID_Stop),
FOREIGN KEY (ID_Line) REFERENCES Line(ID_Line)
);
问题是一辆公共汽车在不同时间在同一个站点停了好几次,我该如何存储这些信息以避免冗余?
例如:
Id_Line = 1
ID_Stop = 1
Hour = 4:50
比
Id_Line = 1
ID_Stop = 1
Hour = 5:20
但这不可能,我想添加另一个名为 ID 的字段(自动增量),但我不知道这是否是最佳解决方案。你有什么建议?
这是我想要的设计
CREATE TABLE Company(
CompanyID SMALLINT IDENTITY(1,1),
CompanyName NVARCHAR(12),
Tel INT,
PRIMARY KEY(CompanyID)
);
CREATE TABLE Line(
LineID INT IDENTITY(1,1),
Code CHAR(3),
CompanyID SMALLINT,
Desc NVARCHAR(MAX),
PRIMARY KEY(LineID),
);
CREATE TABLE [Stop](
StopID INT IDENTITY(1,1),
geoLat NUMERIC(9,6),
geoLong NUMERIC(9,6),
PRIMARY KEY(StopID)
);
CREATE TABLE Make(
MakeID INT IDENTITY(1,1),
StopID INT,
LineID INT,
[Hour] SMALLINT,
PRIMARY KEY(MakeID),
);
我所做的更改以及原因:
- 转换为使用标识列,因为 INT 小于 VARCHAR(3);这一次又一次地在索引上付出代价。
- 已将 VARCHAR 转换为 NVARCHAR。现在增加了国际潜力。
- Desc 现在是 NVARCHAR(MAX),因为 TEXT 是已弃用的数据类型,不应使用。您真的需要那么大的字段来进行描述吗?如果没有,缩小它。
- 主键更新为标识列
- 小时从 TIME 格式更改为 SMALLINT,因为它是一种较小的数据类型,我怀疑您需要估计公交车到达时间以外的时间。 (1720=下午 5:20)
- 您的坐标已降为数字 (9,6)。这应该以尽可能小的数据类型提供您所需的精度。
至于冗余数据,不要被炒作所迷惑。正常化有时间和地点,但不是每次都如此。添加另一个 table 以消除到达时间的冗余实际上会导致您的数据库更大,而不是更小。
您对谓词“[ID_Line] 在时间 [Hour] 停在 [Id_Stop] 感兴趣”。 Table Make as defined 将保留使之成立的行。它唯一的候选键(因此是主键)是 (ID_Stop,ID_Line,Hour) 因为没有其他列子集是唯一的。您的图表应包括小时(根据您使用的任何图表约定)。对于 (ID_Stop,ID_Line) 对(它不会识别 Make 的行,而是曾经停止过的行停止对)或 (ID_Stop,ID_Line,时)三胞胎.
The problem is that a bus stops several times at the same stop in different hours, how could I store this information avoiding redundancy?
没有这个问题。无论是否存在 "redundancy",子行都可以在 table 中出现多次。 (无论你认为那意味着什么。虽然可以用 id 加上另一个 table 替换多次出现的 subrows,然后需要更多 joins 相同的查询结果。见