课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了软件开发数据系统都有哪些常见数据模型类型等内容,而本文我们就继续来学习一下,文本数据库应用需要注意哪些问题。
使应用程序代码更简单方面
如果应⽤程序中的数据具有类似⽂档的结构(即,⼀对多关系树,通常⼀次性加载整个树),那么使⽤⽂档模型可能是⼀个好主意。
关系模型可能导致繁琐的模式和不必要的复杂的应⽤程序代码。
⽂档数据库对连接的糟糕⽀持有可能会是⼀个问题,这取决于应⽤程序。如果你的应⽤程序确实使⽤多对多关系,文档模型通过反规范化可以减少对连接的需求,但是应⽤程序代码需要做额外的⼯作来保持数据的⼀致性。这也将复杂性转移到应⽤程序中,并且通常⽐由数据库内的专⽤代码执⾏的连接慢。在这种情况下,使⽤⽂档模型会导致更复杂的应⽤程序代码和更差的性能。
灵活性方面
⽂档数据库有时称为⽆模式(schemaless),但这具有误导性,因为读取数据的代码通常假定某种结构,即存在隐式模式,但不由数据库强制执⾏。⼀个更精确的术语是读时模式schema-onread:数据的结构是隐含的,只有在数据被读取时才被解释,相应的是写时模式schema-onwrite:传统的关系数据库⽅法中,模式明确,且数据库确保所有的数据都符合其模式。
当由于某种原因(例如,数据是异构的)集合中的项⽬并不都具有相同的结构时,读时模式更具优势。但是,当所有记录都具有相同的结构,那么写时模式是记录并强制这种结构的有效机制。
查询数据的局部性方面
⽂档通常以单个连续字符串形式进⾏存储,编码为JSON,XML或其⼆进制变体(如MongoDB的BSON)。如果应⽤程序经常需要访问整个⽂档(例如,将其渲染⾄⽹⻚),那么存储局部性会带来性能优势。如果将数据分割到多个表中,则需要进⾏多次索引查找才能将其全部检索出
来,这可能需要更多的磁盘查找并花费更多的时间。
局部性仅仅适⽤于同时需要⽂档绝⼤部分内容的情况。数据库通常需要加载整个⽂档,即使只访问其中的⼀⼩部分,这对于⼤型⽂档来说是很浪费的。更新⽂档时,通常需要整个重写。且只有不改变⽂档⼤⼩的修改才可以容易地原地执⾏。这些性能限制⼤⼤减少了⽂档数据库的实⽤场景。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。