Mysql 关系数据库结构逻辑配置

我将使用MySql RDBMS在服务器端开发一个关系数据库

因为这个数据库将包含许多信息，并且会有许多同时的查询，所以我想设置一个优化的结构，以避免检索数据时的缓慢过程

我的名为“account”的主表将包含有关姓名ecc的信息。。用户数量：

 TABLE 'account'

 ID - NAME - SURNAME - AGE

 Primary key -> 'ID'

第二个表将被称为“文件”，它有一个id（外键引用account.id）、一个文件名和一个名为“count”的列：

 TABLE 'file'

 ID - FILENAME - COUNT

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'

我的最后一个表名为“visit”，其结构如下：

 TABLE 'visit'

 ID - FILENAME - OPTION

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'
 Foreign key -> 'FILENAME' -> 'file.FILENAME'

虽然第一个表不会包含很多行，但第二个表可能包含数千行，第三个表可能包含数十万行

也许我错了（我不是db系统管理和优化方面的专家：D），但如果我同时查询包含如此多行的“visit”表并与其他表连接，则过程可能会变慢

这个结构好还是可以改进

最后一个问题，当更新“访问”表时，我是否可以使用“访问”中包含的行数自动更新“文件”->“计数”列，其中“file.filename”=“visit.filename”

或者最好每次都进行类似“从ecc中选择计数（*）这样的查询…”

---

希望我能解释一下，谢谢。

根据您的评论，您的想法听起来不错，但一切都取决于业务，即业务逻辑-如果您正在考虑制作每日报告， 每周、每月访问；如果企业有兴趣了解 过去10年、20年或30年的访问。根据这一点，您可以不时创建一段时间（可能是一年）的历史数据表

正如你所看到的，有很多方法，你也应该考虑到商业的一部分 技术方面，如磁盘空间、备份等，保持 历史数据和持续时间

编辑：

关于你的第二个问题，是的，如果你实现了触发器，你可以。但是你可以检查这个链接，以确保你是否做出了创建触发器的正确决定。（我不喜欢复制和粘贴，所以我更喜欢共享链接，如果我违反了规则，请告诉我）

更新版本2.0:

建议：

尽量不要在列名上使用受限名称（如count、option），我不知道mysql上是否有受限名称，但在SQL SERVER中是的，所以为了便于移植，最好不要使用这样的名称

正如乔纳森·莱夫勒所说，保存年龄不是一个好主意，你可以选择保存生日

---

记录“年龄”通常不是一个好主意；它很快就会出错（平均6个月后，有时是第二天）。DBMS的工作是确保查询工作正常。桌子结构合理。您可以使用触发器来更新计数，但通常最好不要存储可派生的数据，因为最终会出现错误，错误的答案比缓慢的答案更糟糕。对于问题的第二部分，最好每次查询计数。SQL Server速度很快，只要数据被索引（在您的示例中），它就会针对这些信息进行优化。@mrunion主键->{ID'，FILENAME}被认为是主要的耦合，因此可以将ID（'A'）-FILENAME（'A'）和ID（'A'）-FILENAME（'B'）存在到“file”表中。是的，我发现了这一点，并且已经编辑了我的帖子。但是谢谢！谢谢，在性能方面，触发器每次都比选择count（）好吗？考虑每张表上每秒或每分钟的请求，因为这些是主表。还有其他表格，但不太重要。关于历史记录，内容永远不会被删除，应该始终可用。我没有说删除数据，我说的是按年份备份或保存在历史记录表中，类似于2013年访问表，2014年访问表。这取决于生意。@lubilis:计数多长时间会改变一次——任何一个计数？如果少于每秒一次，使用触发器可能无关紧要。如果是每秒数千次，触发器可能会成为一个严重的瓶颈。@JonathanLeffler感谢您的编辑，这里有一个关于何时使用触发器和何时不使用触发器的链接。@Juan Ruiz backup tables似乎是一个好主意，尤其是当某些条件得到验证时。例如，如果在2015年在文件表中插入了一行，我将不在表visit_2013和visit_2014中查询，而只在visit_2015表中查询。否则我将被迫加入表。