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 _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
