擅长:python、mysql、java
<p>在评论中,OP提到了bloat“在数据库中”—但是没有关于他所说的数据库的任何信息;从评论中很少的信息来看,Python字符串片段似乎并不一定涉及什么,相反,“切片”将由DB引擎在检索时完成。</p>
<p>如果这是实际情况,那么我建议在一般原则上不要在数据库中存储冗余信息——一种“正常形式”(可能在表达式的松散意义上是这样的;-),即信息只存储一次,派生信息被重新计算(或数据库引擎的缓存费用等;-)应该是正常的,而“非规范化”则是故意将导出的信息存储得非常多的一种例外,只有在符合特定的、经过良好测量的检索性能需求时才能这样做。</p>
<p>如果对“database”的引用是一个错误的方向;-,或者更确切地说是在一个松散的意义上使用,就像我在上面对“normal form”所做的那样;-),那么另一个考虑可能会适用:由于Python字符串是不可变的,所以不必通过复制来进行切片似乎是很自然的,而是让每一个切片都重用它要从中切片的父内存空间的一部分(就像对numpy数组的切片所做的一样)。不过,这目前还不是Python核心的一部分。我曾经尝试过一个补丁来实现这个目的,但是问题是添加一个对大字符串的引用,从而使它保留在内存中,仅仅是因为它的一个小子字符串仍然被引用,对于一般用途的改编来说,这个小子字符串仍然显得很大。尽管如此,如果大的“父”字符串无论如何都需要保留在内存中,还是可以创建一个特殊用途的string子类(和unicode子类之一)。目前<code>buffer</code>只做了一点点,但是不能在缓冲区对象上调用字符串方法(不首先显式地将其复制到字符串对象),所以它只对输出和一些特殊情况有用。。。但是没有真正的概念块反对添加字符串方法(我怀疑核心中会采用这种方法,但是无论如何,它应该很容易作为第三方模块进行维护;-)。</p>
<p>这样一种方法的价值很难通过测量得到确凿的证明,不管是这样还是那样——速度与当前的隐式复制方法非常相似;其优点完全在于减少内存占用,这不会使任何给定的Python代码更快,而是允许某个程序执行在内存更少的机器上,或者在多个实例同时在不同进程中使用时,多任务更好。请参阅类似于但更丰富的方法的<a href="http://www.sgi.com/tech/stl/Rope.html" rel="nofollow noreferrer">rope</a>,该方法曾经在C++环境中进行过实验(但注意它没有使它成为标准;</p>