On 20 Jun 2005 11:43:28 -0700, rumours say that Oren Tirosh
[EMAIL PROTECTED] might have written:
For very short keys and record (e.g. email addresses) you can use
symbolic links instead of files. The advantage is that you have a
single system call (readlink) to retrieve the contents of a link.
On Tue, 21 Jun 2005 17:00:17 +0300, rumours say that Konstantin
Veretennicov [EMAIL PROTECTED] might have written:
On 6/21/05, Charles Krug [EMAIL PROTECTED] wrote:
Related question:
What if I need to create/modify MS-Access or SQL Server dbs?
You could use ADO + adodbapi for both.
On Mon, 20 Jun 2005 23:42:21 -0800, rumours say that EP
[EMAIL PROTECTED] might have written:
I tried this for one application under the Windows OS and it worked fine...
until my records (text - maybe 50KB average) unexpectedly blossomed into the
10,000-1,000,000 ranges. If I or someone else
Oren suggested:
How about using the filesystem as a database? For the number of records
you describe it may work surprisingly well. A bonus is that the
database is easy to manage manually.
I tried this for one application under the Windows OS and it worked fine...
until my records (text -
On Mon, 20 Jun 2005 23:42:21 -0800, EP wrote:
until my records (text - maybe 50KB average) unexpectedly blossomed into
the 10,000-1,000,000 ranges. If I or someone else (who innocently doesn't
know better) opens up one of the directories with ~150,000 files in it,
the machine's personality
On Mon, 20 Jun 2005 23:42:21 -0800, EP [EMAIL PROTECTED] wrote:
Oren suggested:
How about using the filesystem as a database? For the number of records
you describe it may work surprisingly well. A bonus is that the
database is easy to manage manually.
I tried this for one application
On 6/21/05, Charles Krug [EMAIL PROTECTED] wrote:
Related question:
What if I need to create/modify MS-Access or SQL Server dbs?
You could use ADO + adodbapi for both.
http://adodbapi.sourceforge.net/
- kv
--
http://mail.python.org/mailman/listinfo/python-list
For my database, I have a table of user information with a unique
identifier, and then I save to the filesystem my bitmap files, placing the
unique identifier, date and time information into the filename. Why stick a
photo into a database?
For instance:
User Table:
uniqueID: 0001
lNane: Rose
GMane Python wrote:
For my database, I have a table of user information with a unique
identifier, and then I save to the filesystem my bitmap files, placing the
unique identifier, date and time information into the filename. Why stick a
photo into a database?
There are various possible
Gadfly
PySQLite ( requires SQLite library )
J
Philippe C. Martin wrote:
Hi,
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
As I start with Python
Just thought of a couple more:
SnakeSQL
KirbyBase
J
John Abel wrote:
Gadfly
PySQLite ( requires SQLite library )
J
Philippe C. Martin wrote:
Hi,
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000
Philippe C. Martin wrote:
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
As I start with Python objects, I thought of using shelve, but
On Mon, 20 Jun 2005 15:18:58 GMT, Philippe C. Martin
[EMAIL PROTECTED] said:
Hi,
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
SQLite
Philippe C. Martin wrote:
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
As I start with Python objects, I thought of using shelve, but
John Abel wrote:
Gadfly
PySQLite ( requires SQLite library )
I want to clarify this parenthetical comment, for the record. When I
first downloaded PySQLite I had already gone and installed SQLite,
thinking it was a prerequisite in that sense.
In fact, the PySQLite install includes a .pyd
Well that would be shelve I guess ... with the restrictions I mentioned.
Regards,
Philippe
Erik Max Francis wrote:
Philippe C. Martin wrote:
I am looking for a stand-alone (not client/server) database solution for
Python.
1) speed is not an issue
2) I wish to store less than 5000
Philippe C. Martin wrote:
Well that would be shelve I guess ... with the restrictions I mentioned.
I was talking about pickle, not shelve.
--
Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/
San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis
I used to walk around /
Thank you all for your answers.
A pure Python would have beenmy first choice. yet I now feel I should spend
some time looking at PySQLite (I like the fact it's pre-compiled for
Windows).
Thanks.
Philippe
Philippe C. Martin wrote:
Hi,
I am looking for a stand-alone (not client/server)
You mean pickling a dictionnary of 5000/16K objects ?
Erik Max Francis wrote:
Philippe C. Martin wrote:
Well that would be shelve I guess ... with the restrictions I mentioned.
I was talking about pickle, not shelve.
--
http://mail.python.org/mailman/listinfo/python-list
Philippe C. Martin wrote:
You mean pickling a dictionnary of 5000/16K objects ?
Yes. You said speed was not an issue; pickling only 5000 objects, each
no more than 16 kB, is easily handled by any remotely modern machine
(and even plenty which are not very modern).
--
Erik Max Francis
Philippe C. Martin wrote:
Thank you all for your answers.
A pure Python would have beenmy first choice. yet I now feel I should spend
some time looking at PySQLite (I like the fact it's pre-compiled for
Windows).
Thanks.
Philippe
Philippe C. Martin wrote:
Hi,
I am looking for a
OK, I'll try that too.
Regards,
Philippe
Erik Max Francis wrote:
Philippe C. Martin wrote:
You mean pickling a dictionnary of 5000/16K objects ?
Yes. You said speed was not an issue; pickling only 5000 objects, each
no more than 16 kB, is easily handled by any remotely modern
Philippe C. Martin [EMAIL PROTECTED] wrote:
Hi,
I am looking for a stand-alone (not client/server) database solution
for Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
As I start with Python objects, I thought of
1. 5000 files -- my personal favourite.
You got a point
William Park wrote:
Philippe C. Martin [EMAIL PROTECTED] wrote:
Hi,
I am looking for a stand-alone (not client/server) database solution
for Python.
1) speed is not an issue
2) I wish to store less than 5000 records
3) each
Thanks, I'm looking at KirbyBase also but wonder if it can handle bitmaps (I
could always pickle it first I guess).
Regards,
Philippe
John Abel wrote:
Philippe C. Martin wrote:
Thank you all for your answers.
A pure Python would have beenmy first choice. yet I now feel I should
spend
Correct, that's not a constraint right now.
Paul Rubin wrote:
Philippe C. Martin [EMAIL PROTECTED] writes:
1) speed is not an issue
2) I wish to store less than 5000 records
3) each record should not be larger than 16K
You don't mention whether multiple running programs need to use it
One db that is very much worth trying is Firebird. This is an open
source Interbase 6.0 (Borland product) compatible db. It is a
SourceForge project. There are three versions: the super server which
is a client/server db, classic server (the one that I am very familiar
with) which is also a
Yes, I agree, but as most of the customer base I target uses the O/S that
cannot be named ;-) , file names could become a problem just as 'ln -s' is
out of the question.
Yet, this might be the best trade-off.
Regards,
Philippe
Oren Tirosh wrote:
Philippe C. Martin wrote:
Hi,
I am
I am really surprised that someone hasn't mentioned Gadfly yet. It is a
quick, free, relational database written directly for Python itself.
http://gadfly.sourceforge.net/
Brian
---
Philippe C. Martin wrote:
Hi,
I am looking for a stand-alone (not client/server) database solution for
29 matches
Mail list logo
