Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15662 > unrolled thread

my new project, is this the right way?

Back to article view | Back to comp.lang.python

Contents

  my new project, is this the right way? Tracubik <affdfsdfdsfsd@b.com> - 2011-11-14 10:41 +0000
    Re: my new project, is this the right way? Chris Angelico <rosuav@gmail.com> - 2011-11-14 21:55 +1100
      Re: my new project, is this the right way? HoneyMonster <someone@someplace.invalid> - 2011-11-25 15:44 +0000
        Re: my new project, is this the right way? Chris Angelico <rosuav@gmail.com> - 2011-11-26 02:49 +1100
    Re: my new project, is this the right way? Redcat <redcat@catfolks.net> - 2011-11-14 15:47 +0000
    Re: my new project, is this the right way? Jon Clements <joncle@googlemail.com> - 2011-11-14 08:37 -0800
    Re: my new project, is this the right way? Miki Tebeka <miki.tebeka@gmail.com> - 2011-11-14 09:48 -0800
    Re: my new project, is this the right way? rusi <rustompmody@gmail.com> - 2011-11-25 09:01 -0800
      Re: my new project, is this the right way? Roy Smith <roy@panix.com> - 2011-11-25 12:16 -0500
        Re: my new project, is this the right way? rusi <rustompmody@gmail.com> - 2011-11-25 20:48 -0800
      Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-26 15:41 -0800
        Re: my new project, is this the right way? Dave Angel <d@davea.name> - 2011-11-26 21:35 -0500
          Re: my new project, is this the right way? Roy Smith <roy@panix.com> - 2011-11-26 21:49 -0500
            Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-26 19:14 -0800
              Re: my new project, is this the right way? Chris Angelico <rosuav@gmail.com> - 2011-11-27 14:24 +1100
              Re: my new project, is this the right way? Dave Angel <d@davea.name> - 2011-11-26 22:27 -0500
              Re: my new project, is this the right way? Roy Smith <roy@panix.com> - 2011-11-26 22:41 -0500
        Re: my new project, is this the right way? Matt Joiner <anacrolix@gmail.com> - 2011-11-27 15:03 +1100
          Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-27 00:29 -0800
            Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-27 00:49 -0800
              Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-28 00:51 -0800
              Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-28 00:51 -0800
            Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-27 00:49 -0800
          Re: my new project, is this the right way? 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-27 00:29 -0800

Page 1 of 2  [1] 2  Next page →

#15662 — my new project, is this the right way?

Hi all,
i'm developing a new program.
Mission: learn a bit of database management
Idea: create a simple, 1 window program that show me a db of movies i've 
seen with few (<10) fields (actors, name, year etc) 
technologies i'll use: python + gtk
db: that's the question

since i'm mostly a new-bye for as regard databases, my idea is to use 
sqlite at the beginning.

Is that ok? any other db to start with? (pls don't say mysql or similar, 
they are too complex and i'll use this in a second step)

is there any general tutorial of how to start developing a database? i 
mean a general guide to databases you can suggest to me?
Thank you all

MedeoTL

P.s. since i have a ods sheet files (libreoffice calc), is there a way to 
easily convert it in a sqlite db? (maybe via csv)

[toc] | [next] | [standalone]

#15665

On Mon, Nov 14, 2011 at 9:41 PM, Tracubik <affdfsdfdsfsd@b.com> wrote:
> Hi all,
> i'm developing a new program.
> Mission: learn a bit of database management

If your goal is to learn about databasing, then I strongly recommend a
real database engine.

> since i'm mostly a new-bye for as regard databases, my idea is to use
> sqlite at the beginning.
>
> Is that ok? any other db to start with? (pls don't say mysql or similar,
> they are too complex and i'll use this in a second step)

The complexity, in most cases, is a direct consequence of the job at
hand. I recommend PostgreSQL generally, although I've never used it
with Python and can't speak for the quality of the APIs.

The most important thing to consider is a separation of the back end
(the "guts") from the front end (the "interface"). Since your goal is
to explore databases, the guts of your code will basically just be
working with the database (no heavy computation or anything). Make
sure you can work with that, separately from your GUI. You may find it
easier to dispense with GTK and just work through the console; you can
always change later to make a pretty window.

If you've never worked with databases before, it may be best to skip
Python altogether and explore the fundamentals of relational database
engines. There's plenty of excellent tutorials on the web. Get to know
how things are done generally, and you'll be able to figure out how
things are done in Python.

All the best!

ChrisA

[toc] | [prev] | [next] | [standalone]

#16228

On Mon, 14 Nov 2011 21:55:43 +1100, Chris Angelico wrote:

> On Mon, Nov 14, 2011 at 9:41 PM, Tracubik <affdfsdfdsfsd@b.com> wrote:
>> Hi all,
>> i'm developing a new program.
>> Mission: learn a bit of database management
> 
> If your goal is to learn about databasing, then I strongly recommend a
> real database engine.
> 
>> since i'm mostly a new-bye for as regard databases, my idea is to use
>> sqlite at the beginning.
>>
>> Is that ok? any other db to start with? (pls don't say mysql or
>> similar,
>> they are too complex and i'll use this in a second step)
> 
> The complexity, in most cases, is a direct consequence of the job at
> hand. I recommend PostgreSQL generally, although I've never used it with
> Python and can't speak for the quality of the APIs.
> 
> The most important thing to consider is a separation of the back end
> (the "guts") from the front end (the "interface"). Since your goal is to
> explore databases, the guts of your code will basically just be working
> with the database (no heavy computation or anything). Make sure you can
> work with that, separately from your GUI. You may find it easier to
> dispense with GTK and just work through the console; you can always
> change later to make a pretty window.
> 
> If you've never worked with databases before, it may be best to skip
> Python altogether and explore the fundamentals of relational database
> engines. There's plenty of excellent tutorials on the web. Get to know
> how things are done generally, and you'll be able to figure out how
> things are done in Python.

I agree that given "Mission: learn a bit of database management", Python 
is not really relevant at this stage. I also entirely concur with your 
recommendation of PostgreSQL.

Just for information, PostgreSQL works very well indeed with Psycopg (a 
PostgreSQL adapter for Python), but for learning purposes straightforward 
PSQL is best to start with.

[toc] | [prev] | [next] | [standalone]

#16229

On Sat, Nov 26, 2011 at 2:44 AM, HoneyMonster <someone@someplace.invalid> wrote:
> Just for information, PostgreSQL works very well indeed with Psycopg (a
> PostgreSQL adapter for Python), but for learning purposes straightforward
> PSQL is best to start with.

Thanks for that. I've used PgSQL from C++ (using libpqxx), PHP, Pike,
and the command line, but not from Python. (Yeah, a lot of Ps in
that.)

Once you start looking to write actual code, Python will be an
excellent choice. But master the basics of
database/schema/table/column, primary keys, etc, etc, etc, first.

ChrisA

[toc] | [prev] | [next] | [standalone]

#15670

> since i'm mostly a new-bye for as regard databases, my idea is to use
> sqlite at the beginning.
> 
> Is that ok? any other db to start with? (pls don't say mysql or similar,
> they are too complex and i'll use this in a second step)

I know it's a lot of work to learn initially, but I would recommend 
taking the time to install and become familiar with a database engine 
such as MySQL or PostgresQL. While SQLite is easy to install and easy to 
use, it also cuts a lot of corners and allows you to do things that would 
die in a real database. For example, in SQLite column types are merely 
suggestions; there is nothing in SQLite to keep you from storing a string 
in an integer field or vice versa.

For example:

dan@dan:~/work$ sqlite3
SQLite version 3.7.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table test (
   ...> id int,
   ...> name varchar(64),
   ...> comment varchar(256)
   ...> );
sqlite> .schema test
CREATE TABLE test (
id int,
name varchar(64),
comment varchar(256)
);
sqlite> insert into test values (1, 'Dan', 'Normal insert with valid 
types');
sqlite> insert into test values ('Bogosity', 2, 'Record with invalid 
types');
sqlite> insert into test values ('This field should be an int but is 
really a long string instead', 12.45, 'A really screwy record');
sqlite> select * from test;
1|Dan|Normal insert with valid types
Bogosity|2|Record with invalid types
This field should be an int but is really a long string instead|12.45|A 
really screwy record
sqlite> 


This is not to say that SQLite is useless. Far from it - I use it 
frequently myself. But I've been working with SQL databases for a bunch 
of years, and I am familiar with the tradeoffs involved in working with 
SQLite. 

A decent tutorial on working with SQL in general can be found at http://
www.w3schools.com/sql/sql_intro.asp

Installing MySQL or Postgres can be fairly simple, if you use the tools 
provided with your Linux distro (assuming you're running on Linux). "sudo 
apt-get install mysql mysql-server" or "yum install mysql mysql-server" 
should get you what you need to start using MySQL, "sudo apt-get install 
postgresql" or "yum install postgresql" should get you started with 
PostgresQL.

[toc] | [prev] | [next] | [standalone]

#15674

On Nov 14, 10:41 am, Tracubik <affdfsdfds...@b.com> wrote:
> Hi all,
> i'm developing a new program.
> Mission: learn a bit of database management
> Idea: create a simple, 1 window program that show me a db of movies i've
> seen with few (<10) fields (actors, name, year etc)
> technologies i'll use: python + gtk
> db: that's the question
>
> since i'm mostly a new-bye for as regard databases, my idea is to use
> sqlite at the beginning.
>
> Is that ok? any other db to start with? (pls don't say mysql or similar,
> they are too complex and i'll use this in a second step)
>
> is there any general tutorial of how to start developing a database? i
> mean a general guide to databases you can suggest to me?
> Thank you all
>
> MedeoTL
>
> P.s. since i have a ods sheet files (libreoffice calc), is there a way to
> easily convert it in a sqlite db? (maybe via csv)

I would recommend working through the book "SQL for Dummies". I found
it very clear, and slowly leads you into how to think about design,
not just how to manipulate databases.

Instead of using Python to start with consider using OOo Base or MS
Access (retching noise), so you can use RAD to play with structure and
manipulation of your data and create data-entry forms -- this'll allow
you to enter data, and play with queries and the structure -- as you
won't get it right the first time! You will be able to get either of
these programs to give you the SQL that constructs tables, or makes
queries etc...

That'd be enough to keep you going for a couple of weeks I guess.

Also, some things make more sense in a NoSQL database, so have a look
at something like MongoDB or CouchDB and how their design works
differently.

That's probably another couple of weeks.

Also worth checking out would be http://dabodev.com

hth

Jon.

[toc] | [prev] | [next] | [standalone]

#15682

> since i'm mostly a new-bye for as regard databases, my idea is to use 
> sqlite at the beginning.
> 
> Is that ok? 
I think sqlite3 makes sense since it's already there and has SQL interface.

> is there any general tutorial of how to start developing a database? i 
> mean a general guide to databases you can suggest to me?
The docs (http://docs.python.org/library/sqlite3.html) have some basic instructions.

> P.s. since i have a ods sheet files (libreoffice calc), is there a way to 
> easily convert it in a sqlite db? (maybe via csv)
This can be your first exercise :) But it should be easy to import with the csv module.

[toc] | [prev] | [next] | [standalone]

#16232

On Nov 14, 3:41 pm, Tracubik <affdfsdfds...@b.com> wrote:
> Hi all,
> i'm developing a new program.
> Mission: learn a bit of database management
> Idea: create a simple, 1 window program that show me a db of movies i've
> seen with few (<10) fields (actors, name, year etc)
> technologies i'll use: python + gtk
> db: that's the question
>
> since i'm mostly a new-bye for as regard databases, my idea is to use
> sqlite at the beginning.
>
> Is that ok? any other db to start with? (pls don't say mysql or similar,
> they are too complex and i'll use this in a second step)
>
> is there any general tutorial of how to start developing a database? i
> mean a general guide to databases you can suggest to me?
> Thank you all
>
> MedeoTL
>
> P.s. since i have a ods sheet files (libreoffice calc), is there a way to
> easily convert it in a sqlite db? (maybe via csv)

To learn DBMS you need to learn sql
[Note sql is necessary but not sufficient for learning DBMS]
I recommend lightweight approaches to start with -- others have
mentioned access, libreoffice-base.
One more lightweight playpen is firefox plugin sqlite-manager

> Is that ok? any other db to start with? (pls don't say mysql or similar,
> they are too complex and i'll use this in a second step)

Correct. First you must figure out how to structure data -- jargon is
normalization.
After that you can look at transactions, ACID, distribution and all
the other good stuff.

[toc] | [prev] | [next] | [standalone]

#16233

In article 
<581dab49-e6b0-4fea-915c-4a41fa887c3b@p7g2000pre.googlegroups.com>,
 rusi <rustompmody@gmail.com> wrote:

> First you must figure out how to structure data -- jargon is 
> normalization. After that you can look at transactions, ACID, 
> distribution and all the other good stuff.

And when you're all done with that, you can start unlearning everything 
you've learned about normalization (not that you shouldn't learn about 
it in the first place, just that you should also learn when excessive 
normalization is a bad thing).

And then start looking at BASE (Basic Availability, Soft-state, 
Eventually consistent) as an alternative to ACID.

Don't get me wrong.  SQL is a powerful tool, and truly revolutionized 
the database world.  Anybody who is thinking about going into databases 
as a career needs to know SQL.  But, it's not the end of the road.  
There is life after SQL, and that's worth exploring too.

[toc] | [prev] | [next] | [standalone]

#16246

On Nov 25, 10:16 pm, Roy Smith <r...@panix.com> wrote:
> In article
> <581dab49-e6b0-4fea-915c-4a41fa887...@p7g2000pre.googlegroups.com>,
>
>  rusi <rustompm...@gmail.com> wrote:
> > First you must figure out how to structure data -- jargon is
> > normalization. After that you can look at transactions, ACID,
> > distribution and all the other good stuff.
>
> And when you're all done with that, you can start unlearning everything
> you've learned about normalization (not that you shouldn't learn about
> it in the first place, just that you should also learn when excessive
> normalization is a bad thing).
>
> And then start looking at BASE (Basic Availability, Soft-state,
> Eventually consistent) as an alternative to ACID.
>
> Don't get me wrong.  SQL is a powerful tool, and truly revolutionized
> the database world.  Anybody who is thinking about going into databases
> as a career needs to know SQL.  But, it's not the end of the road.
> There is life after SQL, and that's worth exploring too.

Yes going all the way up to fifth normal form can be nonsensical.
Putting it less jargony -- Given a real world scenario involving data
can you organize it into tables with reasonable foreign-key relations,
and integrity constraints? If so you can start looking beyond sql.

[toc] | [prev] | [next] | [standalone]

#16269

On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
> On Nov 14, 3:41 pm, Tracubik <affdfs...@b.com> wrote:
> > Hi all,
> > i'm developing a new program.
> > Mission: learn a bit of database management
> > Idea: create a simple, 1 window program that show me a db of movies i've
> > seen with few (<10) fields (actors, name, year etc)
> > technologies i'll use: python + gtk
> > db: that's the question
> >
> > since i'm mostly a new-bye for as regard databases, my idea is to use
> > sqlite at the beginning.
> >
> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> > they are too complex and i'll use this in a second step)
> >
> > is there any general tutorial of how to start developing a database? i
> > mean a general guide to databases you can suggest to me?
> > Thank you all
> >
> > MedeoTL
> >
> > P.s. since i have a ods sheet files (libreoffice calc), is there a way to
> > easily convert it in a sqlite db? (maybe via csv)
> 
> To learn DBMS you need to learn sql
> [Note sql is necessary but not sufficient for learning DBMS]
> I recommend lightweight approaches to start with -- others have
> mentioned access, libreoffice-base.
> One more lightweight playpen is firefox plugin sqlite-manager
> 
> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> > they are too complex and i'll use this in a second step)
> 
> Correct. First you must figure out how to structure data -- jargon is
> normalization.
> After that you can look at transactions, ACID, distribution and all
> the other good stuff.

If I have a fast hash library  that each hash function supports insertion and deletion and can be frozen to be stored into the file system if desired and retrieved lator . Can I use several hashes to replace a database that is slow and expensive?
 

[toc] | [prev] | [next] | [standalone]

#16274

On 11/26/2011 06:41 PM, 88888 Dihedral wrote:
> On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
>> On Nov 14, 3:41 pm, Tracubik<affdfs...@b.com>  wrote:
>>> Hi all,
>>> i'm developing a new program.
>>> Mission: learn a bit of database management
>>> Idea: create a simple, 1 window program that show me a db of movies i've
>>> seen with few (<10) fields (actors, name, year etc)
>>> technologies i'll use: python + gtk
>>> db: that's the question
>>>
>>> since i'm mostly a new-bye for as regard databases, my idea is to use
>>> sqlite at the beginning.
>>>
>>> Is that ok? any other db to start with? (pls don't say mysql or similar,
>>> they are too complex and i'll use this in a second step)
>>>
>>> is there any general tutorial of how to start developing a database? i
>>> mean a general guide to databases you can suggest to me?
>>> Thank you all
>>>
>>> MedeoTL
>>>
>>> P.s. since i have a ods sheet files (libreoffice calc), is there a way to
>>> easily convert it in a sqlite db? (maybe via csv)
>> To learn DBMS you need to learn sql
>> [Note sql is necessary but not sufficient for learning DBMS]
>> I recommend lightweight approaches to start with -- others have
>> mentioned access, libreoffice-base.
>> One more lightweight playpen is firefox plugin sqlite-manager
>>
>>> Is that ok? any other db to start with? (pls don't say mysql or similar,
>>> they are too complex and i'll use this in a second step)
>> Correct. First you must figure out how to structure data -- jargon is
>> normalization.
>> After that you can look at transactions, ACID, distribution and all
>> the other good stuff.
> If I have a fast hash library  that each hash function supports insertion and deletion and can be frozen to be stored into the file system if desired and retrieved lator . Can I use several hashes to replace a database that is slow and expensive?
>
If you're using Python, you already have a "fast hash" library, in the 
dictionary class.  And yes, if a problem doesn't need the full 
generality of a database, you may be able to implement it with 
dictionaries, and it may even be practical to store those dictionaries 
to disk for later retrieval.  However, there are quite a few reasons 
this may not be good enough.  To start with just two:   if there are 
multiple users of the database, and they have to be synched.  Or if you 
have to be safe from a program or a system crashing.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#16275

In article <mailman.3067.1322361338.27778.python-list@python.org>,
 Dave Angel <d@davea.name> wrote:

> If you're using Python, you already have a "fast hash" library, in the 
> dictionary class.  And yes, if a problem doesn't need the full 
> generality of a database, you may be able to implement it with 
> dictionaries, and it may even be practical to store those dictionaries 
> to disk for later retrieval.  However, there are quite a few reasons 
> this may not be good enough.  To start with just two:   if there are 
> multiple users of the database, and they have to be synched.  Or if you 
> have to be safe from a program or a system crashing.

This is a good point.  In general, databases differ from in-memory data 
structures in that they provide:

1) Persistence

2) Data integrity

3) Shared access

Different kinds of databases provide different amounts and flavors of 
these (especially #2).  I think it's fair to say, however, that those 
three in some form are essential for something that calls itself a 
database.

Where thing get fun is when you start looking at the various things out 
there that call themselves databases and need to evaluate which ones 
give you the combination of these that best match your needs.

[toc] | [prev] | [next] | [standalone]

#16277

On Sunday, November 27, 2011 10:49:20 AM UTC+8, Roy Smith wrote:
> In article <mailman.3067.1322361...@python.org>,
>  Dave Angel <d...@davea.name> wrote:
> 
> > If you're using Python, you already have a "fast hash" library, in the 
> > dictionary class.  And yes, if a problem doesn't need the full 
> > generality of a database, you may be able to implement it with 
> > dictionaries, and it may even be practical to store those dictionaries 
> > to disk for later retrieval.  However, there are quite a few reasons 
> > this may not be good enough.  To start with just two:   if there are 
> > multiple users of the database, and they have to be synched.  Or if you 
> > have to be safe from a program or a system crashing.
> 
> This is a good point.  In general, databases differ from in-memory data 
> structures in that they provide:
> 
> 1) Persistence
> 
> 2) Data integrity
> 
> 3) Shared access

Shared in access in a local lan or a wide wan?

In python there are packages can solve these easily.  

[toc] | [prev] | [next] | [standalone]

#16278

On Sun, Nov 27, 2011 at 2:14 PM, 88888 Dihedral
<dihedral88888@googlemail.com> wrote:
> Shared in access in a local lan or a wide wan?
>

That question isn't inherent to databasiness; it might not even be
network-shared at all - in fact, most database-driven web sites have a
database that's accessible only from localhost (which is where the web
server runs). It's still shared access, and has all the same concerns.

ChrisA

[toc] | [prev] | [next] | [standalone]

#16279

On 11/26/2011 10:14 PM, 88888 Dihedral wrote:
> On Sunday, November 27, 2011 10:49:20 AM UTC+8, Roy Smith wrote:
>> <SNIP>
>> This is a good point.  In general, databases differ from in-memory data
>> structures in that they provide:
>>
>> 1) Persistence
>>
>> 2) Data integrity
>>
>> 3) Shared access
> Shared in access in a local lan or a wide wan?
>
> In python there are packages can solve these easily.

Right, and they are not in-memory databases.

or to go back to the OP in this fork of the thread, they are not "fast 
hashes."

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#16280

In article 
<26232548.146.1322363676465.JavaMail.geo-discussion-forums@pruu5>,
 88888 Dihedral <dihedral88888@googlemail.com> wrote:

> > In general, databases differ from in-memory data 
> > structures in that they provide:
> > 
> > 1) Persistence
> > 
> > 2) Data integrity
> > 
> > 3) Shared access
> 
> Shared in access in a local lan or a wide wan?

Well, like I said in my original post, "Different kinds of databases 
provide different amounts and flavors of these".  Sharing across a 
network is one type of shared access, but there are lots of things that 
don't do network access that I would still consider databases.

[toc] | [prev] | [next] | [standalone]

#16281

Sounds like you want a key-value store. If it's a lot of data, you may
still want a "database", I think it's just relational databases that
you're trying to avoid?

On Sun, Nov 27, 2011 at 10:41 AM, 88888 Dihedral
<dihedral88888@googlemail.com> wrote:
> On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
>> On Nov 14, 3:41 pm, Tracubik <affdfs...@b.com> wrote:
>> > Hi all,
>> > i'm developing a new program.
>> > Mission: learn a bit of database management
>> > Idea: create a simple, 1 window program that show me a db of movies i've
>> > seen with few (<10) fields (actors, name, year etc)
>> > technologies i'll use: python + gtk
>> > db: that's the question
>> >
>> > since i'm mostly a new-bye for as regard databases, my idea is to use
>> > sqlite at the beginning.
>> >
>> > Is that ok? any other db to start with? (pls don't say mysql or similar,
>> > they are too complex and i'll use this in a second step)
>> >
>> > is there any general tutorial of how to start developing a database? i
>> > mean a general guide to databases you can suggest to me?
>> > Thank you all
>> >
>> > MedeoTL
>> >
>> > P.s. since i have a ods sheet files (libreoffice calc), is there a way to
>> > easily convert it in a sqlite db? (maybe via csv)
>>
>> To learn DBMS you need to learn sql
>> [Note sql is necessary but not sufficient for learning DBMS]
>> I recommend lightweight approaches to start with -- others have
>> mentioned access, libreoffice-base.
>> One more lightweight playpen is firefox plugin sqlite-manager
>>
>> > Is that ok? any other db to start with? (pls don't say mysql or similar,
>> > they are too complex and i'll use this in a second step)
>>
>> Correct. First you must figure out how to structure data -- jargon is
>> normalization.
>> After that you can look at transactions, ACID, distribution and all
>> the other good stuff.
>
> If I have a fast hash library  that each hash function supports insertion and deletion and can be frozen to be stored into the file system if desired and retrieved lator . Can I use several hashes to replace a database that is slow and expensive?
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#16282

On Sunday, November 27, 2011 12:03:26 PM UTC+8, Matt Joiner wrote:
> Sounds like you want a key-value store. If it's a lot of data, you may
> still want a "database", I think it's just relational databases that
> you're trying to avoid?
> 
> On Sun, Nov 27, 2011 at 10:41 AM, 88888 Dihedral
> <dihedr...@googlemail.com> wrote:
> > On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
> >> On Nov 14, 3:41 pm, Tracubik <affd...@b.com> wrote:
> >> > Hi all,
> >> > i'm developing a new program.
> >> > Mission: learn a bit of database management
> >> > Idea: create a simple, 1 window program that show me a db of movies i've
> >> > seen with few (<10) fields (actors, name, year etc)
> >> > technologies i'll use: python + gtk
> >> > db: that's the question
> >> >
> >> > since i'm mostly a new-bye for as regard databases, my idea is to use
> >> > sqlite at the beginning.
> >> >
> >> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> >> > they are too complex and i'll use this in a second step)
> >> >
> >> > is there any general tutorial of how to start developing a database? i
> >> > mean a general guide to databases you can suggest to me?
> >> > Thank you all
> >> >
> >> > MedeoTL
> >> >
> >> > P.s. since i have a ods sheet files (libreoffice calc), is there a way to
> >> > easily convert it in a sqlite db? (maybe via csv)
> >>
> >> To learn DBMS you need to learn sql
> >> [Note sql is necessary but not sufficient for learning DBMS]
> >> I recommend lightweight approaches to start with -- others have
> >> mentioned access, libreoffice-base.
> >> One more lightweight playpen is firefox plugin sqlite-manager
> >>
> >> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> >> > they are too complex and i'll use this in a second step)
> >>
> >> Correct. First you must figure out how to structure data -- jargon is
> >> normalization.
> >> After that you can look at transactions, ACID, distribution and all
> >> the other good stuff.
> >
> > If I have a fast hash library  that each hash function supports insertion and deletion and can be frozen to be stored into the file system if desired and retrieved lator . Can I use several hashes to replace a database that is slow and expensive?
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >

A database with most entries in fixed bytes and types and several  types that can have varied lengths of 8 to 256 bytes. If an entry is larger than 256 bytes, it will be saved as a file but only the file name is saved in my data base.
  
Each entry is just a type and value stored  in a row of my database.
I''ll limit the number of entries in a row or so called a recored to some limit first, 1024 first. 
   
Can I do this in 1024 hashes in python ?

[toc] | [prev] | [next] | [standalone]

#16284

On Sunday, November 27, 2011 4:29:52 PM UTC+8, 88888 Dihedral wrote:
> On Sunday, November 27, 2011 12:03:26 PM UTC+8, Matt Joiner wrote:
> > Sounds like you want a key-value store. If it's a lot of data, you may
> > still want a "database", I think it's just relational databases that
> > you're trying to avoid?
> > 
> > On Sun, Nov 27, 2011 at 10:41 AM, 88888 Dihedral
> > <dihe...@googlemail.com> wrote:
> > > On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
> > >> On Nov 14, 3:41 pm, Tracubik <aff...@b.com> wrote:
> > >> > Hi all,
> > >> > i'm developing a new program.
> > >> > Mission: learn a bit of database management
> > >> > Idea: create a simple, 1 window program that show me a db of movies i've
> > >> > seen with few (<10) fields (actors, name, year etc)
> > >> > technologies i'll use: python + gtk
> > >> > db: that's the question
> > >> >
> > >> > since i'm mostly a new-bye for as regard databases, my idea is to use
> > >> > sqlite at the beginning.
> > >> >
> > >> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> > >> > they are too complex and i'll use this in a second step)
> > >> >
> > >> > is there any general tutorial of how to start developing a database? i
> > >> > mean a general guide to databases you can suggest to me?
> > >> > Thank you all
> > >> >
> > >> > MedeoTL
> > >> >
> > >> > P.s. since i have a ods sheet files (libreoffice calc), is there a way to
> > >> > easily convert it in a sqlite db? (maybe via csv)
> > >>
> > >> To learn DBMS you need to learn sql
> > >> [Note sql is necessary but not sufficient for learning DBMS]
> > >> I recommend lightweight approaches to start with -- others have
> > >> mentioned access, libreoffice-base.
> > >> One more lightweight playpen is firefox plugin sqlite-manager
> > >>
> > >> > Is that ok? any other db to start with? (pls don't say mysql or similar,
> > >> > they are too complex and i'll use this in a second step)
> > >>
> > >> Correct. First you must figure out how to structure data -- jargon is
> > >> normalization.
> > >> After that you can look at transactions, ACID, distribution and all
> > >> the other good stuff.
> > >
> > > If I have a fast hash library  that each hash function supports insertion and deletion and can be frozen to be stored into the file system if desired and retrieved lator . Can I use several hashes to replace a database that is slow and expensive?
> > >
> > > --
> > > http://mail.python.org/mailman/listinfo/python-list
> > >
> 
> A database with most entries in fixed bytes and types and several  types that can have varied lengths of 8 to 256 bytes. If an entry is larger than 256 bytes, it will be saved as a file but only the file name is saved in my data base.
>   
> Each entry is just a type and value stored  in a row of my database.
> I''ll limit the number of entries in a row or so called a recored to some limit first, 1024 first. 
>    
> Can I do this in 1024 hashes in python ?
Sorry I 'll use (k=column_in_a_row, v=value) and (k=value, v=column_in_a_row)
Thus, two hashes per column in  my database, therefore  2048 hashes to manage the data base. I'll reserve 24 entries per row for book keeping. 
Thus the record can have 1000 entries maximum first. 
The number of record can be very large. 
Each value will be a string with type 1 byte  and the stored value 8 to 255 bytes represented as a string when fetching the value can be auto-transformed 
according to the type.  The sort and search will be rewritten for the comparison operator. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web