Python / Apache / MySQL

V

vpr

Hi All

I want to build an Website using Apache / Python and MySQL.
I dont want to spend to much time hacking html. I'm looking for some
recommendations
e.g. should I be using mod_python ?
whats the best module for mysql ?

any suggestings so I could get my site up in a day ?

(e-mail address removed)
 
B

bruno at modulix

vpr said:
Hi All

I want to build an Website using Apache / Python and MySQL.

Good choice, good choice, bad choice...
Why not using PostgresSQL (if you need a *real* RDBMS) or SQLite (if you
don't...)
I dont want to spend to much time hacking html. I'm looking for some
recommendations
e.g. should I be using mod_python ?

mod_python is mostly a 'low-level' Apache API binding. Better use a
higher-level tool on top of it. AFAICT, Myghty might be of some help here.
whats the best module for mysql ?

Psycopg ?-)

oops, sorry....
any suggestings so I could get my site up in a day ?

Look for Myghty, Pylons (built on Mygthy), or Django. There's also
Turbogears, but it's based on CherryPy, so you won't really take
advantage of mod_python's Apache integration.
 
S

Sybren Stuvel

vpr enlightened us with:
I want to build an Website using Apache / Python and MySQL.

I second Bruno: swap MySQL in favour of PostgreSQL.
e.g. should I be using mod_python ?

You could use my framework based on mod_python and Cheetah. I find it
really easy to use. Check out http://www.unrealtower.org/webengine
whats the best module for mysql ?

I'd use SQLObject. It can handle MySQL (if you really want to stick to
it), SQLite and PostgreSQL.

Sybren
 
K

Kalle Anke

I second Bruno: swap MySQL in favour of PostgreSQL.

And the reason is ?? (apart from PostgreSQL being larger and more complete,
what are the differences for "simple" usage?)

jem
 
B

bruno at modulix

Kalle said:
And the reason is ?? (apart from PostgreSQL being larger and more complete,
what are the differences for "simple" usage?)

The reason is mostly that either you need a real, full-blown, rock-solid
RDBMS - which MySQL is definitively not - or you dont - in which case
SQLite is probably a much more lightweight and agile solution.

My 2 cents
 
K

Kalle Anke

The reason is mostly that either you need a real, full-blown, rock-solid
RDBMS - which MySQL is definitively not - or you dont - in which case
SQLite is probably a much more lightweight and agile solution.


Stupid questions (I know very little about databases):

I always thought that a SQLlite database "belonged" to a single process, can
a database be used by several processes?

Let's say I would build a small web application that would be used by a small
number of people/processes and it wouldn't be anything fancy just basic
"selects". What would be the choice for this?

What about speed? I've always had the impression that while PostgreSQL is
more complete than MySQL it's also slower.

Sorry, if these are really stupid questions but ...

jem
 
P

Peter Hansen

Kalle said:
I always thought that a SQLlite database "belonged" to a single process, can
a database be used by several processes?

Depending on what you mean by "belong", that's either true or false.
Certainly multiple processes can access a SQLite database, although as
the documentation clearly describes if those processes are making
_frequent updates_ it's not the best solution and another database might
be more suitable.
Let's say I would build a small web application that would be used by a small
number of people/processes and it wouldn't be anything fancy just basic
"selects". What would be the choice for this?

SQLite. (As but one option, but "just basic selects" is certainly
included in the set of suitable conditions for SQLite use.)
What about speed? I've always had the impression that while PostgreSQL is
more complete than MySQL it's also slower.

Don't optimize prematurely? If you use something like SQLObject, or any
other means of abstracting yourself away from the details of a specific
datbase, you won't be particularly tied to it if you decide you need
improved performance, or sophistication, or whatever.
Sorry, if these are really stupid questions but ...

They're not.
 
S

Sybren Stuvel

Kalle Anke enlightened us with:
What about speed? I've always had the impression that while
PostgreSQL is more complete than MySQL it's also slower.

For simple queries, I believe (no real knowledge here) MySQL is indeed
faster. One of the problems I have with MySQL is that it doesn't
support foreign keys nor transactions on the default table format.

Sybren
 
K

Kalle Anke

SQLite. (As but one option, but "just basic selects" is certainly
included in the set of suitable conditions for SQLite use.)

I've considered to use SQLite for an application but for completely different
reasons ... hmm, I should perhaps consider SQLite for some other ideas I have
also ...
Don't optimize prematurely? If you use something like SQLObject, or any
other means of abstracting yourself away from the details of a specific
datbase, you won't be particularly tied to it if you decide you need
improved performance, or sophistication, or whatever.


That's true ... I was thinking in general terms here (a couple of people I
know handles huge data sets, genome data type of things, and in their case
speed is very important)
 
?

=?iso-8859-1?q?Luis_M._Gonz=E1lez?=

Just a few comments...

Database:
As with anything else, try to keep it simple until you need to make it
complex.
Sqlite is the simplier alternative, and it's also the fastest for the
intended use (small number of users, simple selects, etc). MySQL is
also a very good alternative and much more powerful.

Mod_python:
Mod_python is the best choice (AFAIK, please correct me if I'm wrong)
if you want speed, performance and scalability. Many frameworks are
based on mod_python (Django, for example), so you can't go wrong with
it.
But let me tell you that if you just want to use bare-bones mod_python,
without any framework on top of it, you can do it, and it's not
difficult at all.
Mod_python comes with its own implementation of PSP (python server
pages), which lets you program a la PHP (intermingling python and
html).
If you want, you can also separate logic and presentation by using its
"publisher handle" along with PSP templates. If you prefer other kinds
of templetaing system, you can use them too (for example Cheetah).

For a long time I steered away of mod_python because I had the
impression it was too difficult and not user friendly enough, what once
I tried and followed the examples in the documentation, I found it to
be a very good alternative.
And the community on its mailing list is very kind and supportive. They
reply any question in a matter of minutes.
 
P

Peter Hansen

Kalle said:
That's true ... I was thinking in general terms here (a couple of people I
know handles huge data sets, genome data type of things, and in their case
speed is very important)

There is information about SQLite speed starting here
http://www.sqlite.org/speed.html (where it notes that that particular
page is obsolete, but also points to the wiki for more).

The summary would appear to be that SQLite is definitely faster in some
cases, definitely slower in others, and that as usual a measurement of
inadequate speed followed by profiling is essential to knowing what to
do about any of that. :)

-Peter
 
D

Dennis Lee Bieber

For simple queries, I believe (no real knowledge here) MySQL is indeed
faster. One of the problems I have with MySQL is that it doesn't
support foreign keys nor transactions on the default table format.
I believe that since 4.1, the "default table format" is InnoDB, and
that DOES have some support foreign keys and transactions. (and 5.x has
added basic stored procedures/triggers)

--
 
S

Sybren Stuvel

Dennis Lee Bieber enlightened us with:
I believe that since 4.1, the "default table format" is InnoDB, and
that DOES have some support foreign keys and transactions.

Finally they are starting to make more sense. I'd still rather use a
database that has had those features for a longer time, though.

Sybren
 
P

Paul Boddie

Sybren said:
Dennis Lee Bieber enlightened us with:

Finally they are starting to make more sense. I'd still rather use a
database that has had those features for a longer time, though.

My experience with MySQL on the abomination that is Fedora Core (so I
imagine it was 4.x as opposed to 5.x), was that the default table type
appeared to be the ridiculously incapable MyISAM, and that by choosing
InnoDB you got transactions along with a bunch of limitations and a
serving of odd behaviour, where "odd" means "would raise a laugh
amongst users of other database systems".

I think you only really need to compare the manuals for MySQL [1] and
PostgreSQL [2] to see that PostgreSQL offers straightforward but
seemingly well-tested functionality for populating databases and then
having them just work properly, whereas MySQL offloads an array of
"features" and a mangled SQL syntax onto the developer/administrator in
a way that would suggest, if one were to be uncharitable in this
matter, that the developers of MySQL aren't confident that everything
works and would rather "empower" users to make their own choices and
then to apologise for themselves when something they thought might work
(and probably would on some other system) actually doesn't.

Anyway, various comparisons have been made, and here are a few
good/recent ones:

http://www.wlug.org.nz/PostgresVsMysql
http://sql-info.de/mysql/gotchas.html
http://sql-info.de/postgresql/postgres-gotchas.html

And here's one with a Pythonic slant:

http://bob.pythonmac.org/archives/2005/08/12/mysql-hate/

Paul

[1] http://dev.mysql.com/doc/refman/5.0/en/
[2] http://www.postgresql.org/docs/7.4/static/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,236
Members
46,822
Latest member
israfaceZa

Latest Threads

Top