简述数据库物理设计的主要内容。

说实话，这六件事看起来像是教科书上的标准流程，但实际操作起来却没有那么简单。
我之前接手了一个老系统，数据存储结构只是一个“历史问题”。
未找到代码注释。
最后只好靠着当时的老运维听写，硬着头皮重写了。
这次事件让我明白，第一件事“定义一个数据存储结构”绝对不是画图那么容易，需要了解历史。

有趣的是，索引设计主要测试你的视野。
我见过开发直接将所有数据插入一张大表的项目，查询时直接烧CPU。
然后，我们转向分表分库，性能立刻提升了三个级别。
当时我想，这不是设计指标，这只是“看、听、问”——你需要了解数据的特点，然后才能对症下药。

关于存储位置，我发现了一个奇怪的情况。
某公司的数据在本地服务器上，但地震彻底摧毁了机房。
第二天他们就后悔了，无论谁建议放手，现在都是英雄。
但说实话，尽管云存储很棒，但仍然取决于客户的预算。
并非所有小企业主都是这样。

系统配置比较复杂。
错误的参数设置可能会导致数据丢失。
我的一个朋友调试了系统，将备份频率设置为每小时一次。
结果客户家突然断电，所有数据瞬间丢失。
当时，他差点被老板解雇，然后他不得不熬夜从冷备份中恢复数据。
这让我想起配置参数应该像相亲一样。
你必须一遍又一遍地测试它，看看它是否合适。

数据存储的形式更加多样化。
我见过有些人使用XML来存储配置，有些人使用二进制文件来存储日志，还有一些人直接使用数据库作为文件系统。
坦白说，形式并不重要，重要的是下一个维护人员能否看得懂。
一名实习生几乎搞乱了生产数据，因为他无法理解他的前老板创建的“神秘”二进制格式。
最后，我把火扑灭了。

最后，就安全性而言，我见过的最糟糕的事情是以明文形式存储密码的银行系统。
当时技术负责人告诉我，“所有东西都是内部加密的，所以没问题”。
结果，黑客介入并窃取数据。
这让我认为安全不仅仅是安装防火墙，它的根源必须是残酷的。

只有实现了这几点，系统才能运行。
但过程不会遵循套路，每一步都必须根据实际情况进行调整。
就像做饭一样，食谱是一个参考。
如果真的好吃，那就要看厨师了。

数据库逻辑设计和物理设计包含哪些内容