[python-win32] advice on architecting or program design in python:

Tim Golden mail at timgolden.me.uk
Tue Mar 11 11:14:29 CET 2008


mark.a.brand wrote:
> hi:
> 
> i am new to python and wish but am writing a program as both a learning
> experience and which may even get used if it is any good.

Welcome to the wonderful world of Python :)

> purpose of this program:
> is to retrieve and store (for historical purposes) system-info for multiple
> clients about multiple windows servers using tim golden's
> wmi<http://tgolden.sc.sabren.com/python/wmi.html>wrapper. broadly the
> algorithm is something like this.
> 
> for each client
>     for each server
>         get-info(Win32_Process()))
>         get-info(get-Win32_Service())
>         ...
>         ...
>         write-system-info (to-a-db)
>     endfor
> endfor

Not that it's necessarily wrong, but it's not clear why you're bothering
to pull server information from each client separately. It's not as
though the services running on Server S1 will appear different when
queried from client C1 and C2. But maybe there's something I'm missing.

[... snip slightly confused post which seems to be mixing
RDBMS terminology and class queries ...]

I'd love to help you out here, Mark, but it's not entirely clear
whether you're asking for advice on RDBMS structures (what tables
to use for the data) or class structures (how to fit the data
returned into classes).

Wearing my database hat for a moment, it seems as though the
most obvious table structure from your description above is
(Noddy structure - I don't usually create a bunch of V(100 fields):

CREATE TABLE
   services
(
   client VARCHAR (100),
   server VARCHAR (100),
   name VARCHAR (100),
   status VARCHAR (100)
.
.
etc
)

CREATE TABLE
   processes
(
   client VARCHAR (100),
   server VARCHAR (100),
   name VARCHAR (100),
   status VARCHAR (100)
.
.
etc
)

Now, if what you're saying is: hey, they all seem to have .Caption,
.Status, .Name attributes; surely some sort of denormalisation applies
here, then I would say: Beware. It's terribly tempting to create a
database-within-a-database without any real gain. Unless it's really
offering you something to create a wmi_objects table with 1:1
subordinates, don't do it.

As to the class structure within Python, the same sort of caveats apply.
Use Python core data structures -- lists, dicts, sets, tuples -- as much
as you possibly can. They're simple and well-defined and they're
optimized to hell and back (not least since they're used by Python
itself as part of its internals). Don't feel you have to go around
creating hierarchies of classes just because you can!

Anyway, if that wasn't what you were after, or if you want to explain
your plans further feel free to post back.

TJG



More information about the python-win32 mailing list