> > hi: > > <snip> > 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> > > sorry - client as in customer > > <snip> > CREATE TABLE > processes > ( > client VARCHAR (100), > server VARCHAR (100), > name VARCHAR (100), > status VARCHAR (100) > . > . > etc > ) > </snip> > > thats what i have > > <snip> > 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. > </snip> > > no - the db structure you outlined above is fine. > > i will try and explain better, but its not quite clear in my mind what is > achievable ... > > so to build up these database tables, i have to have some queries > happening of the form : > > for list in Win32_Process() > add instance to table-process > > for list in Win32_Service() > add instance to table-service > > ... > etc etc for each Win32_* query i wanted to implement. > > what I am looking for is an object based / pythonic way to replace all > those "for loops". it just seemed to me that the "for loops" only differ in > the Win32_* class they call. so for example would i: > > * define a class Service() and a class Process () and put a method in each > class that contained the above for loop. > or > > * define a class Service() and a class Process() and a class Manager() and > put the for loops in the Manager class > > now both of these ways strike me as being clumsy, so I was looking for a > better way to represent this behaviour. > > thanks for you assistance tim. > > cheers > mark > > > > On 11/03/2008, Tim Golden <[EMAIL PROTECTED]> wrote: > > > > 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 > > > >
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32