我的数据库中有一张表,用于存储有21个可用性插槽的用户可用性信息:每周3天。它看起来像这样:用户可用性表的数据库设计
CREATE TABLE user_availability(
id int(11) primary key increments,
user_id int(11),/*foreign key*/
day_mon tinyint(1),
day_tues tinyint(1),
day_wed tinyint(1),
day_thurs tinyint(1),
day_fri tinyint(1),
day_sat tinyint(1),
day_sun tinyint(1),
eve_mon tinyint(1),
eve_tues tinyint(1),
eve_wed tinyint(1),
eve_thurs tinyint(1),
eve_fri tinyint(1),
eve_sat tinyint(1),
eve_sun tinyint(1),
late_mon tinyint(1),
late_tues tinyint(1),
late_wed tinyint(1),
late_thurs tinyint(1),
late_fri tinyint(1),
late_sat tinyint(1),
late_sun tinyint(1)
);
这似乎是在第一个是超级简单拉可用性特定USER_ID和简单映射到形式等一个好主意,但我已经意识到这是一个糟糕的设计与数据在错误的地方有效地强制在应用程序中处理表之间的关系而不是在数据库中处理。
我的新设计是有2个表:
create table user_availabilty(
id int(11) primary key increments,
user_id int(11),/*foreign key*/
time_slot tinyint(2)/*foreign key*/
);
create table time_slots(
id tinyint(2) primary key,
name varchar(20)
);
这有什么问题呢?如果有一天我的梦想成真,并且我拥有数以万计的用户,那么每个用户的表中可能会有21行可能会出现问题?
“成本”将保持不变,因为这些项目的数量是固定的。那么目的是什么?这些信息的预期用途是什么?查询会是什么样子? –
预期用途是将承包商与租用人匹配。 “查询会是什么样子?”好点子!我开始回答'从usr_avail中选择不同的user_id,其中time_slot = 1和time_slot = 2',我认为这并不适用于所提出的想法。嗯,这并不理想 – kemika