数据库和python [英] Databases and python
问题描述
我已经花了一点时间在
python的文件索引引擎中，你可以在这里找到：
http://dcs.nac.uci.edu/~strombrg/pyindex。 HTML
它现在可以很好地完成40,000个不同长度的邮件，但是我想要更多的b / b $ b / b
到目前为止，我一直在采用单表数据库的方法
像gdbm或dbhash（实际上是少数几个，用于映射文件名到
数字，数字到文件名，单词到数字，数字到单词，
和编号的单词到编号的文件名），并使每个条目键入
a word，在数据库中的单词下面是一个空终止的
文件名列表（在 http://dcs.nac.uci.edu/~strombrg/base255.html 表示。
但是，尽管使用了 http://dcs.nac.uci.edu/~strombrg/cachedb.html 模块
使数据库使用更快，引入psyco，并学习各种
python优化页面，该程序只是表现得不像我想要的那样。
而且我认为它''因为尽管有缓存和最小代表性转换，但是仍然只是将线性列表转换为数组来回太慢，而且来回和来回都是b $ b。 >
所以这让我想知道 - 是否有一个python数据库接口
允许我定义一个表的时间？就像，每个单词变成一个
表，然后该表中的字段只是
包含该单词的文件名。这样就可以将文件名添加到一个单词中，这根本不会让b $ b b下来。
-But-，是否存在任何python的数据库接口如果你试图给他们成千上万的桌子，你会有点不高兴吗？
谢谢！
推荐答案
我不是BDB的专家，但是我花了相当多的时间用PostgreSQL和Oracle工作
。听起来你需要在你的算法和数据表示中加入一些
优化。
我会做的非常像你在做，除了我只会有以下关系
：
- 单词ID到单词
- 文件名到文件名ID
- 文字ID到文件名ID
你将要在这个
数据库的几乎每一列上都有一个索引。那是因为你要通过这些
列中的任何一列查找相应的值。
我说我不是BDB专家。但我确实有一些经验
建立大型数据库。在第一阶段，您只需积累数据
。然后，只在需要时构建索引。让我们说
你正在扫描你的文件。你不需要
文件名到ID表的索引。那是因为你只是把数据放在
那里。 word-to-ID表需要单词的索引，但不需要ID
（你还没有通过ID查找。）和单词ID-to-filename ID table
也不需要任何索引。因此，在没有
索引的情况下构建数据。一旦你的扫描完成，然后建立你需要常规操作的b / b
的索引。您可以逐步添加数据为
。
至于文件名ID和单词ID，只需使用计数器生成
下一个号码。如果您使用base255作为数字，那么您真的不会为了节省更多空间而花费很多。
您对数十万个表的想法？很坏。不要这么做吧。
I''m no expert in BDBs, but I have spent a fair amount of time working
with PostgreSQL and Oracle. It sounds like you need to put some
optimization into your algorithm and data representation.
I would do pretty much like you are doing, except I would only have the
following relations:
- word to word ID
- filename to filename ID
- word ID to filename ID
You''re going to want an index on pretty much every column in this
database. That''s because you''re going to lookup by any one of these
columns for the corresponding value.
I said I wasn''t an expert in BDBs. But I do have some experience
building up large databases. In the first stage, you just accumulate
the data. Then you build the indexes only as you need them. Let''s say
you are scanning your files. You won''t need an index on the
filename-to-ID table. That''s because you are just putting data in
there. The word-to-ID table needs an index on the word, but not ID
(you''re not looking up by ID yet.) And the word ID-to-filename ID table
doesn''t need any indexes yet either. So build up the data without the
indexes. Once your scan is complete, then build up the indexes you''ll
need for regular operation. You can probably incrementally add data as
you go.
As far as filename ID and word IDs go, just use a counter to generate
the next number. If you use base255 as the number, you''re really not
going to save much space.
And your idea of hundreds of thousands of tables? Very bad. Don''t do
it.
Dan Stromberg：
Dan Stromberg:
是否有python数据库界面，这将允许我定义一个表格？就像，每个单词成为一个表，然后该表中的字段只是包含该单词的文件名。
is there a python database interface that would allow me to define a
-lot- of tables? Like, each word becomes a table, and then the fields
in that table are just the filenames that contained that word.
尝试使用ZODB。
http://www.zope.org/Wikis/ZODB/FrontPage
http://www.python.org/workshops/2000...ton/zodb3.html
我的第一次尝试是：一个BTree，单词为key和''
文件名'列表'作为值。
http://www.zope.org/Wikis/ZODB/Front...00000000000000
-
$ b $bRenéPijlman
Give ZODB a try.
http://www.zope.org/Wikis/ZODB/FrontPage
http://www.python.org/workshops/2000...ton/zodb3.html
My first attempt would be: a BTree with the word as key, and a ''list of
filenames'' as value.
http://www.zope.org/Wikis/ZODB/Front...00000000000000
--
René Pijlman
Jonathan Gardner写道：
Jonathan Gardner wrote:
我不是BDB的专家，但是我花了一个公平的amo与PostgreSQL和Oracle一起工作的时间。听起来你需要对你的算法和数据表示进行一些优化。
我会像你一样做，除了我只有
以下的关系：
- 单词ID
- 文件名到文件名ID
- 单词ID到文件名ID
你想要一个索引在这个
数据库的几乎每一列上。
停止！
我不是数据库专家，但是把索引放在各处都很好
已知的DB反模式。索引仅在索引字段足够判别时才有用（即：必须有较少的可能记录，其中
为该字段的值相同）。否则，索引查找可能会比简单的线性查找花费更多的时间来结束
。此外，索引减慢了写入操作的价值。
这是因为你要通过这些
列中的任何一列查找相应的值。
我说我不是BDB的专家。但我确实有一些建立大型数据库的经验。在第一阶段，您只需积累数据。然后，只在需要时构建索引。
是的。只有它才能产生感觉。
（剪辑）
您对数十万桌的想法？很坏。不要这样做。
I''m no expert in BDBs, but I have spent a fair amount of time working
with PostgreSQL and Oracle. It sounds like you need to put some
optimization into your algorithm and data representation.
I would do pretty much like you are doing, except I would only have the
following relations:
- word to word ID
- filename to filename ID
- word ID to filename ID
You''re going to want an index on pretty much every column in this
database.
stop !
I''m not a db expert neither, but putting indexes everywhere is well
known DB antipattern. An index is only useful if the indexed field is
discriminant enough (ie: there must be the less possible records having
the same value for this field). Else, the indexed lookup may end up
taking far more time than a simple linear lookup. Also, indexes slow
down write operations.
That''s because you''re going to lookup by any one of these
columns for the corresponding value.
I said I wasn''t an expert in BDBs. But I do have some experience
building up large databases. In the first stage, you just accumulate
the data. Then you build the indexes only as you need them.
Yes. And only where it makes sens.
(snip)
And your idea of hundreds of thousands of tables? Very bad. Don''t do
it.
+100这个
-
bruno desthuilliers
python -c" print''@''。join（[''。''。join（[w [:: - 1] for p in p.split（''）。 ''）]）
p in''o **** @ xiludom.gro''。split（''@''）]）"
+100 on this
--
bruno desthuilliers
python -c "print ''@''.join([''.''.join([w[::-1] for w in p.split(''.'')]) for
p in ''o****@xiludom.gro''.split(''@'')])"
这篇关于数据库和python的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
