我有一个有趣的问题,我一直在研究,并希望得到一些建议:
我正在尝试创建一个工具,模仿需求管理工具的基本功能,作为公司项目的一部分.
基本设计是类似于Windows资源管理器的文件夹和文档设置.可以在GUI中打开文档,编辑和保存文档.
该文档本身包含一个分层电子表格(如果有意义的话,可以考虑带有章节的Excel).每章都包含行,这些行实际上只是一些需求文本+其他一些补充它的值.显示时,需求文本和属性值显示为独立列(非常类似于Excel),具有过滤功能.
为这种类型的程序代表用户/权限/文件夹层次结构/等是非常简单的,但我被挂断的地方是文档内容本身......
我最关心的是尺寸以及它与性能的关系:作为这个工具的一部分,我不仅打算存储每个文档的当前状态,还要存储自第1天以来所做的全部更改列表(很像SVN) ,然后提供快速访问更改历史记录.
平均而言,我希望回购中有大约500份文件; 每个文档可能有大约20,000个活动行; 在一年的时间里,假设约20,000次编辑并不是不合理的(这意味着每个文档本身将逐年获得额外的20,000行).
乘以文件数量,相当于近10,000,000行(明年还有10,000,000,明年等等).可以清除旧历史,但只能由管理员执行(并且他/她这样做并不可取).
我认为,有两种方法可以解决这种情况:
我可以尝试在一个表中表示所有文档的所有行的列表(很像phpBB如何在一个表中存储所有论坛的所有帖子),或者......
我可以尝试将每个文档的行存储在一个唯一命名的表中(意味着每个文档都有自己的表); 该表必须具有唯一的名称,主表将包含所有文档的列表以及与每个文档对应的表名.
所以我的问题:哪个更好？既不是很好的选择吗？任何人都可以根据需要提供有关哪种方法更合适的建议？
如果您在应用程序的正常日常操作期间以编程方式创建和/或销毁表,我会说这是一个非常糟糕的迹象,表明数据库设计中的某些内容是错误的.
数据库系统可以并且确实处理具有那么多行的表.要对该行数进行任何有意义的查询,您必须仔细而节俭地选择索引.我的意思是,你真的必须亲密地知道如何查询表格.
但是,我敢说,与你提出的基于ID或数字任意创建新表的方法相比,实现起来要简单得多.并且,由于更少的复杂性,更容易维护,并且您将引入难以调试的令人讨厌的错误的可能性更小.
如果您真的热衷于分成多个表,那么我建议您研究其他人如何进行数据分区.不是动态创建表,而是根据您认为可能需要的数量从一开始就创建固定数量的表,并根据某些任意事物(例如表中的表中有多少记录)将记录分配给这些表.时间,但在可预测的事情上 - 用户的邮政编码是给定的示例,或文档所在的类别,或创建它的用户的域名或国家,或者可以用来轻松确定记录位置的逻辑结束了它将合理地分散.
以这种方式创建所有分区的数据分区的一个好处是,如果您将来需要移动到多个数据库服务器相对容易.如果您正在动态创建和销毁表,那将会降低这一点.
京公网安备 11010802040832号 | 京ICP备19059560号-6 