我是设计数据库的新手,我不确定我是否在为我的应用程序设计数据库时正确实现了规范化和关系。
正在设计的应用程序适用于购物清单和产品,并将按如下方式使用数据库:
我有“尝试”为数据库创建两种不同的设计,试图推断哪种设计可能更适合该方案。一个使用一对多关系,一个多对多关系,两者都将 shopping_list 链接到产品:
问题:
关于一对多:鉴于将有数百万种不同的产品ID,一对多设计不会产生 assigned_products 表中的大量冗余信息?产品表的字段类似于:
________________________________________________
|assigned_p_id | shopping_list_id | product_code |
|--------------+------------------+--------------|
| 1 | 1 | aa11aab |
|--------------+------------------+--------------|
| 2 | 1 | zz1bbbb |
|--------------+------------------+--------------|
| 3 | 2 | aa11aab |
正如您所看到的,aa11aab
重复了两次,因为其他人创建了具有相同项目的购物清单,因此我想知道这种冗余是否会产生数据库问题,每个重复的product_code会占用不必要的空间量?
关于多对多:该图似乎通过使表 shopping_list_products 存储ID值而不是重复product_code来消除冗余,但是,HOWEVER ,这会在检索信息时导致性能下降吗?我假设必须在表之间进行一些加入,以便每个用户获得所有购物清单和购物清单中的产品代码。
一般来说:我的人际关系/规范化可能有任何错误吗? (我是这个领域的新手)
答案 0 :(得分:0)
以下是从哪里开始的一些建议。
您需要一张表来存储有关购买的信息。在数据中你可以看到Wile E Coyote购买了Dyno-might和钢琴......
CREATE TABLE IF NOT EXISTS `purchase` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`user_id` int unsigned NOT NULL,
`item_id` int unsigned NOT NULL,
`quantity` double DEFAULT 1,
`price` double NOT NULL,
`qwhen` datetime NOT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (`user_id`) REFERENCES user(id) ON DELETE RESTRICT ON UPDATE CASCADE,
FOREIGN KEY (`product_id`) REFERENCES product(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Purchases';
purchase data
+----+---------+------------+----------+--------+---------------------+
| id | user_id | product_id | quantity | price | created |
+----+---------+------------+----------+--------+---------------------+
| 1 | 1 | 1 | 1 | 100.00 | 2016-07-02 20:42:13 |
| 1 | 1 | 3 | 1 | 734.23 | 2016-07-02 21:23:40 |
| .. | ....... | .......... | ........ | ...... | ................... |
+----+---------+------------+----------+--------+---------------------+
您还需要一个表来存储有关产品的信息。我假设您正在销售实体产品,因此我添加了ean
,upca
以及其他一些可能有帮助的专栏。
CREATE TABLE IF NOT EXISTS `product` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`manufacturer_id` int unsigned NOT NULL,
`ean` int unsigned NOT NULL,
`upca` int unsigned NOT NULL,
`upce` int unsigned NOT NULL,
`name` varchar(100) NOT NULL,
`height` double DEFAULT NULL,
`width` double DEFAULT NULL,
`depth` double DEFAULT NULL,
`weight` double DEFAULT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (`manufacturer_id`) REFERENCES manufacturer(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Item master file';
product data
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+
| id | manufacturer_id | ean | upca | upce | name | height | width | depth | weight |
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+
| 1 | 1 | 1234567890123 | 123456789012 | 123456 | Dyno-might | 12.0 | 1.0 | 1.0 | 0.5 |
| 2 | 1 | 2345678901234 | 234567890123 | 234567 | UltraLaser | 96.0 | 96.0 | 96.0 | 450.0 |
| 3 | 2 | 3456789012345 | 345678901234 | 345678 | Piano | 36.0 | 60.0 | 72.0 | 375.0 |
| .. | ............... | ............. | ............ | ...... | .......... | ...... | ..... | ..... | ...... |
+----+-----------------+---------------+--------------+--------+------------+--------+-------+-------+--------+
当我们向人们出售产品时,我们很高兴正式解决这些问题,所以我们应该有一个有效的称呼表。 user
表将具有此表的外键。
CREATE TABLE IF NOT EXISTS `salutation` (
`id` varchar(5) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB Comment='Salutations';
salutation data
+------+
| id |
+------+
| Mr. |
| Mrs. |
| Miss |
| Ms. |
| Dr. |
| Rev. |
| .... |
+------+
名称后缀是个人姓名的一部分,因此我们将制作user
表的该部分,并为此表提供外键。
CREATE TABLE IF NOT EXISTS `suffix` (
`id` varchar(5) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB Comment='Suffixes';
suffix data
+-----+
| id |
+-----+
| Sr. |
| Jr. |
| II |
| III |
| IV |
| ... |
+-----+
当然我们有用户 - 尽管称他们为客户可能更合适。
CREATE TABLE IF NOT EXISTS `user` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`facebook_id` int unsigned NOT NULL,
`email` varchar(255) NOT NULL,
`salutation_id` varchar(5) NOT NULL,
`first_name` varchar(50) NOT NULL,
`middle_name` varchar(50) DEFAULT NULL,
`last_name` varchar(50) NOT NULL,
`suffix_id` varchar(5) DEFAULT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (`salutation_id`) REFERENCES salutation(id) ON DELETE RESTRICT ON UPDATE CASCADE,
FOREIGN KEY (`suffix_id`) REFERENCES suffix(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB Comment='Users';
user data
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+
| id | facebook_id | email | salutation_id | first_name | middle_name | last_name | suffix_id |
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+
| 1 | 123456789 | coyote_guy32@gmail.com | Mr. | Wile | E | Coyote | NULL |
| .. | ........... | ...................... | ............. | .......... | ........... | ......... | ......... |
+----+-------------+------------------------+---------------+------------+-------------+-----------+-----------+
答案 1 :(得分:0)
在这两种情况下,你基本上都在做同样的事情。在第一种情况下,您将shopping_list_id
映射到product_code
,在第二种情况下,您将其映射到product_id
。无论您使用product_code
还是product_id
,它们似乎都是代表product
实体的外键。在这两种情况下,要到达产品行,您必须使用该字段加入products
表。
作为一般规则,您应该映射两个id
列(第二个选项),以便在两种情况下使用整数主键完成连接。这不仅可以提高存储和索引的效率,还可以使这些连接速度更快。
另外,正如其中一条评论指出的那样,您应该将自动增量主键添加到shopping_list_products
表中。
另外,对于命名约定,您可能需要考虑始终使用id
命名主键。例如,您没有拥有products.product_id
,而是拥有products.id
等等,而且每张桌子都有。{/ p>