在数据库设计方面,我主要是自学成才。我提出这个问题是因为我已经确定了这种通用结构,但我想知道它是否是最有效的或“行业标准”方法。
我设计的大多数数据库都有一个用户表,然后在另一个表中跟踪人员活动。我知道数据库的美妙之处在于具有这些效率,但是活动表将相当快地从每个定期使用它的用户那里收集许多事件,从而在中等用户使用情况下相当快地成为一个巨大的表。这是让它以这种方式增长的最佳实践吗?或者是一层表,还是根据日期、用户数量或其他原因拆分到不同的表?
+--------------------+ +------------------------+
| UserData | | Activity |
+-=------------------+ +------------------------+
| ID (auto uint) | <--1-to-many-+ | ID (auto uint) |
| UserName (text) | +--> | UserID (uint) |
| Email (text) | | Timestamp (time) |
| additional info... | | Type (ID to elsewhere) |
+--------------------+ | additional info... |
+------------------------+
Run Code Online (Sandbox Code Playgroud)
我只是想知道我可以在哪里改进任何东西,以帮助我学习。
过去,我将所有通用设置和配置项(例如:自定义应用程序标题、家庭地址、版本、调试等)存储在“settings.php”文件中,我会将其包含在所有脚本中。
我认为最好为这些应用程序设置专门设置一个数据库表,这样您就不需要编辑 php 文件来调整或进行更改。然而,我对如何设置这个有点谨慎。
我一直在考虑两种选择:
从数据库设计的角度来看,有什么建议或我应该注意的事情吗?
我之前问过一个问题“存储用户事件数据的正确技术”,我认为正确的答案是创建一个数据库分区。现在,从我读到的内容来看,有不同的分区方法,但是对于这个问题,我们将假设我们正在使用 RDBMS(例如 MySQL)上的日期字段进行水平键分区...(如果您有异议或对此的争论,无论如何都做出贡献)。
基本问题是您如何知道要创建多少个分区?
我知道这是一个相当悬而未决的问题,因为它也将严重依赖于您运行它的硬件,但无论哪种方式,都应该有一些指导方针可以指出更好的性能在哪里,或者这样做的正确方法,甚至你会如何判断这样的事情?我发现的大多数文档都使用诸如“大”、“大”、“很多”之类的术语……这些术语在访问速度、行数、效率与存储或所需硬件方面的含义是什么。是不是从反复试验或观察到的性能开始,如果事情开始变得有点粗糙,您只需添加一两个分区?
我对大型数据库方案中这个看似常见的障碍的意见和矛盾非常感兴趣。
谢谢
database-design database-recommendation database-tuning partitioning