[Tutor] database applications with Python - where to start

William O'Higgins william.ohiggins at utoronto.ca
Thu May 5 16:52:31 CEST 2005


On Thu, May 05, 2005 at 02:03:30PM +0100, Barnaby Scott wrote:
>Hi, this is one of those difficult questions about where to start!
>
>I want to create a book-keeping/accounting application for my own use
>1. because I can't find any that suits me, and
>2. because I want to improve and extend my knowledge of Python.

Good reasons for doing something - just remember that, as you are
discovering, this is a pretty extensive project, and the reasons need to
be good enough if you are to finish.

>Clearly this is going to be a database application - the trouble is, that
>despite reading loads of stuff (including previous posts here on the topic),
>I get a Catch-22 feeling that I need to be an expert with 'the big picture'
>before I can even take my first stumbling steps towards becoming that
>expert!

This is a very reasonable response when you look at a project and begin
to appreciate its complexities.

I am the opposite of a Python expert (most of the code I read leaves me
with questions and confusion - that's why I'm lurking here), but I know
something about problem-solving.  Here is an approach that may help:

Programming is, by definition, something that can be decomposed into
smaller problems.

When you are thinking about your project, write everything you think of
down.  Once it is written down, attempt to break up your notes into
categories - features, behaviours, functional activities of the finished
product.  This does not need to take a long time.

Once you think you have a collection of things you need from your
project (these are called Requirements by many), try to organize them 
by type: data storage, data manipulation, human interfaces, computer
systems interfaces, etc.

Now, take one of these aspects at a time, and try to quantify what
exactly this piece of the project needs to do - for example, write data
into a database.  Once you have in your head a clear picture of one
activity of your program, write a small piece of code that does what you
want.  If it doesn't work, ask for help - small problems are easier to
solve (generally) than big ones, and always easier to ask for help
about.  Something that helps is to make each proof of concept script
with a name that relates back to your Requirements document - so you
know by the file name how it fits in the whole project.

At some point you will have to commit to which tools you are going to
use (database, language, interface, etc.).  For your first major
project, try to use what you know, or what you have the best support
systems in place for - local gurus, lists, user groups etc.  Even while
you commit to one set of tools, try to think of your program as a set of
interacting pieces that can be abstracted from one another, so if you
need to change one piece the whole structure doesn't collapse (this is
called "loose coupling").

>how/where to start. I'm tempted to try to put together a 'kit' of tools (as
>visual as possible) to emulate what I'm used to - but is this a good idea?
>and if so, which tools? 

Tool kits are very worthwhile - once you have code that works, you'll
reuse it a lot.  Which tools comes down to an optimization of your
ability and comfort, your support network and features. 

> What on earth is my application's model going to
>look like? should I get involved with object-relational mapping? 

If it will gain you something yes, if you don't understand what the
gains are or how to implement them, probably not.

>how much work should I delegate to the RDBMS, and how much logic should
>I code in Python? 

If you decide at some other point to change databases, delegating core
functions to the database may hurt.  If you decide to re-write your
project in C later, you may regret not handing some things to the
database.  In all cases, try not to reinvent the wheel habitually, but
only where it serves a purpose (learning how it works is a purpose).

>Should I even be thinking radically and ditch the RDBMS in favour of
>something like a 'Prevalence Layer' that I have read about? what should
>inform these decisions?

What do you *really* understand, and what can you implement without
having an aneurysm.

>I just don't know where to start! A book perhaps, but then, which one? Or
>maybe an example app for me to pick apart and learn from?

Look for an Open Source app that almost works the way you need it to,
and look at how it's done.  You may find that getting involved with an
existing project will get you the features you need sooner than building
something from scratch, and by getting involved you can learn a lot.

>Sorry it is such a vague question, but any pointers gratefully received.

Vague questions are hard to answer specifically, but they are often
worth asking.  You may find more success decomposing your vague
questions into specific sub-questions - they are easier to answer
quickly.
-- 

yours,

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/tutor/attachments/20050505/7d8a08cc/attachment.pgp


More information about the Tutor mailing list