如何设计一个简单的数据库

分析需求，找出用户想要什么，是最困难、最耗时的一步。

概念设计、需求筛选和概念建模非常重要。

逻辑设计，将概念转化为数据模型并对其进行优化。

物理设计，选择适合环境的存储和访问方法。

在部署阶段，使用工具来部署数据库是一个重要的步骤。

购物网站数据库设计

嘿嘿，你说的这个方法……听起来很方便。

想一想，以前的方法是每个产品一张表。
比如我2 02 2 年在北京做的一个项目，产品类型只有几十种，但是附加了几十张表。
数据库管理几乎是疯狂的。
如果推出一个新产品，比如智能冰箱，就得另外加一块板子，还要改代码，非常混乱。

你提到的四个表，品类名称表、品类属性表、商品名称表、商品属性表……这个确实不错。
类别名称表包含类别ID和类别名称。
例如：1 是电脑，2 是洗衣机。
类别属性表分隔每个类别的属性。
例如，电脑有CPU、内存和屏幕尺寸，洗衣机有容量和类型。
这很好。
如果稍后更新计算机并添加固态驱动器，只需向目录属性表添加一个条目，无需对计算机表进行任何更改。

然后，产品名称列表就是具体的产品，属于哪个类别，比如电脑1 ，电脑2 ，洗衣机1 ，洗衣机2 产品属性表对应的是这个产品的属性值。
例如：电脑1 有P4 CPU，1 2 8 M内存，CRT屏幕尺寸，洗衣机1 有9 公斤容量，滚筒类型。
这样，如果您想添加新机器或更改洗衣机的颜色，只需在产品属性表中更改即可，而不必担心其他表。

你是对的。
要定义新产品或修改现有产品，操作员只需单击鼠标即可。
这种结构实际上可以适应很多不同的产品，一般不会改变数据库结构，因此程序不需要做大幅度的修改。
2 02 2 年，我的另一个客户使用了这种结构，他们报告说它更容易维护。

关于电商网站数据库的设计有什么好的建议？

那天我在仓库整理东西时，看到一堆电脑、衣服、家居用品，种类繁多。
我心想，如果用传统的数据库来管理，那该是多么复杂啊。
例如，计算机的“CPU”字段和服装的“颜色”字段可以合并吗？这显然是不合适的。
而且每个产品都有上百个属性，都堆在一张表里，查询起来非常慢。

等一下，我突然想到我们之前有一个服装电商项目，他们使用MongoDB来存储产品信息。
这样，每个产品就是一个文档，不用担心属性多，性能也不成问题。
此外，他们还使用 ElasticSearch 进行搜索。
用户一搜索就能瞬间找到自己想要的产品。

这让我思考，为什么我们不能把产品分为公开信息和高级信息呢？必须整合公共信息，例如产品 ID、名称、商家和日期，因此需要使用数据库。
计算机CPU、显卡、服装款式和颜色等高级信息可以按产品类型进行扩展，并使用文档数据库或专用扩展表进行管理。

2 01 9 年，项目上线后，搜索速度肯定更快了，用户反馈也更好了。
不过我还是想，如果有一天产品种类多了，这个方法还管用吗？