Re: [Zope] Zope Digest, Vol 91, Issue 2
Hi John and FernandoIntuitively I feel that my project fits in with an Object DB, which is why I have spent a lot of time trying to understand its methodology. But now I'm more confused than ever. To answer your questions - Only an expert can perform data entry for the tools, obviously. Since I have no clue how to enter data into mySQL or ZODB I have no idea what's in store for me. The ultimate goal is for the engine to become an expert system that is capable of taking inputs, learning from mistakes, scraping data from reports and from the internet, and become better and better at its predictions. The logic engine will get better and more complex as more tools are added - but once all the 'current' tools are added, the system must be able to go 'solo', with an accuracy that reaches six sigma levels. As Fernando has suggested, I will have to go with C/C++, or even my own language in the future, but that day is far off. I plan to start with 50 higher-level tools and try to build a prototype. The front-end is really very simple. The choices available for the start parameters and end parameters are pretty basic, and most of the logic happens under the hood - probably at the back end if possible. Once I've built this prototype, I will know whether mqSQL can handle scaling up (in my particular case). If not, I can confidently invest in ZODB. If I can make my position any clearer in order to get a conclusive answer either way - I'll be glad to. Thanks again for your help. I really am indebted to you guys.sareesh
From: zope-request@zope.org Subject: Zope Digest, Vol 91, Issue 2 To: zope@zope.org Date: Mon, 5 Dec 2011 12:00:02 +0000
Send Zope mailing list submissions to zope@zope.org
To subscribe or unsubscribe via the World Wide Web, visit https://mail.zope.org/mailman/listinfo/zope or, via email, send a message with subject or body 'help' to zope-request@zope.org
You can reach the person managing the list at zope-owner@zope.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope digest..."
Today's Topics:
1. Re: Help in deciding approach to Web App (Fernando Martins) 2. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 3. Re: Help in deciding approach to Web App (Fernando Martins) 4. Re: Help in deciding approach to Web App (John Schinnerer) 5. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 6. Re: Help in deciding approach to Web App (Fernando Martins) 7. Re: Help in deciding approach to Web App (John Schinnerer) 8. Re: Help in deciding approach to Web App (Niels Dettenbach) 9. Re: Help in deciding approach to Web App (Fernando) 10. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 11. Re: Help in deciding approach to Web App (Niels Dettenbach)
----------------------------------------------------------------------
Message: 1 Date: Sun, 04 Dec 2011 13:28:36 +0100 From: Fernando Martins <fernando@cmartins.nl> To: Sareesh Sudhakaran <aysand@hotmail.com> Cc: zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App Message-ID: <4EDB6774.1050603@cmartins.nl> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/04/2011 09:52 AM, Sareesh Sudhakaran wrote:
Thanks Niels. Just to clarify: Does my particular instance fall under an OODBMS model or a RDBMS model (with ORM if necessary)?
Data modelling is a bit of an art and probably you could tackle your problem with any approach. I think the important is for you to figure out which model suits more your personality. No kidding.
I would personally start with the RDBMS approach considering only the information you provide. Also, you can easily use zope in combination with a RDBMS. When you read the book, beware that zope has been changing from a "through the web" approach, to a typical file system based approach, which is a loss, but it seems to be what suits the needs of the zope developers.
The approach I use is:
zpt page -> (one) Python Script -> (some) ZSQL Methods -> MySQL
The zpt defines the layout of the pages, the ZSQL Methods retrieve the data needed and the Python script massages the data to make it suitable for the ZPT page. Or the other way around, from user input in a form to storage in the database.
The advantage of the relational approach is that it is a very well understood model and although different people will still come to different models there are sufficient objective guidelines out there (e.g., the normalization rules, and then criteria for when to denormalise) to help you along. Furthermore, there are lots of people in db-related forums that can help you.
Also, RDBMS provides you with a "standard" query language, SQL, which plenty of systems and tools can use. In general, RDBMS gives you the safest approach to keep your data and not loose it when you need to migrate either the front-end or the back-end. This language is very powerful and can avoid you a lot of low level programming.
However, plenty of people can not deal well with SQL because it follows a paradigm so different from the classic imperative programming. With SQL, you specify the "what", with the other languages you specify the "how". The advantage of the "what" is that you can do a lot of data processing in a few lines of code. The problem with the "what" is that because you don't know the "how" of it, you feel you don't have control and you are led to say the language is "obscure" or "unreadable".
However, even if you are not comfortable with the "what" (you have to try to know), you can still rely on an library like SQLAlchemy to keep you a bit in the comfort zone of the "how". So instead of learning SQL, you need to learn the API of a specific library. Your choice. I recommend the first by far.
The real main issue with Relational is that it is a highly structured data model. It allows you to keep high quality data but if you don't get it right soon enough in the development cycle, some later changes can have a huge impact in the application, requiring rewrites. Furthermore, it works the best when you have many objects with the same properties. If you have many entities all different from each other (the tools in your case, maybe), then maybe a OODBMS might be better. But here, there is no standard language, or standard whatever. Perosnally, I would avoid as much as possible to put data in something like ZODB (I use it merely to store and manage the application).
The problem with your specific case is that it does not seem to be a typical case of books and authors, which might be a risk for someone without experience. The issue "Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000", is indeed tricky. I suspect in general the needs of your system will be too specific to be able to rely only on SQL queries. You would need to put a lot of intelligence in the data (really highly structured) and it might become unmanageable or not scalable.
I guess you will need to put a lot of intelligence in the Python Script. So, the ZSQL retrieves the relevant tool data and then makes the tool choice. The knowledge of the meaning of the attributes is maintained in programming.
I should say I am not totally sure the Python Script is the best approach here, in terms of management facilities. But Python is surely a very good language due to its readability. However, you might need to use External methods or a more typical file-system based Python approach.
Or maybe you actually need to create a Domain Specific Language to encode the intelligence needed for your tool selection process. If your python code becomes repetitive, with patterns showing up, then a DSL might be a good approach, but this might be too much engineering for you at this stage. It looks like you are in a typical CIM scenario and I remember handling a similar problem 20 years ago. I vaguely remember at that time to use custom graph structures in C and the the intelligence was coded in Lisp/Scheme. So, there is a big range of solutions to try out :)
If you have time, then the simple approach
zpt page -> (one) Python Script -> (some) ZSQL Methods -> MySQL database
might be a good starting point. You should not need to spend much time to implement a prototype using this approach. In the worse case scenario it helps you understand better your problem and what could be a better approach with little investment. Essentially you try the classical approach and if it does not work well, either you are doing something wrong, or you have a better understanding of your needs and where to go.
Good luck, Fernando
Aloha, I think you might want a "both and" approach rather than an "either or" approach. In which case Niels' comments re the ability to use both objects/object DB and relational DB in python/zope applications are highly relevant. If you go with an object-based combination like python/zope/ZODB where you can also use/integrate relational data, then you can use each model/data approach where most appropriate for what you're building. It sounds like there may be some of both, as you describe an eventual "expert system" app. If you use PHP or most any other HTML-munging/scripting platform that I'm aware of, you are crippled in terms of using 'true' OO programming methods (useful for an 'expert system') and object DB where they are most appropriate. Especially for the size and flexibility of what you are aiming for, a 'true' OO language seems essential. In short, you don't have to do object DB *or* RDB - you can use both, if using a platform that supports that such as zope. cheers, John S. On 12/05/2011 04:12 AM, Sareesh Sudhakaran wrote:
Hi John and Fernando Intuitively I feel that my project fits in with an Object DB, which is why I have spent a lot of time trying to understand its methodology. But now I'm more confused than ever.
To answer your questions -
Only an expert can perform data entry for the tools, obviously. Since I have no clue how to enter data into mySQL or ZODB I have no idea what's in store for me.
The ultimate goal is for the engine to become an expert system that is capable of taking inputs, learning from mistakes, scraping data from reports and from the internet, and become better and better at its predictions. The logic engine will get better and more complex as more tools are added - but once all the 'current' tools are added, the system must be able to go 'solo', with an accuracy that reaches six sigma levels. As Fernando has suggested, I will have to go with C/C++, or even my own language in the future, but that day is far off.
I plan to start with 50 higher-level tools and try to build a prototype. The front-end is really very simple. The choices available for the start parameters and end parameters are pretty basic, and most of the logic happens under the hood - probably at the back end if possible. Once I've built this prototype, I will know whether mqSQL can handle scaling up (in my particular case). If not, I can confidently invest in ZODB.
If I can make my position any clearer in order to get a conclusive answer either way - I'll be glad to. Thanks again for your help. I really am indebted to you guys. sareesh
From: zope-request@zope.org Subject: Zope Digest, Vol 91, Issue 2 To: zope@zope.org Date: Mon, 5 Dec 2011 12:00:02 +0000
Send Zope mailing list submissions to zope@zope.org
To subscribe or unsubscribe via the World Wide Web, visit https://mail.zope.org/mailman/listinfo/zope or, via email, send a message with subject or body 'help' to zope-request@zope.org
You can reach the person managing the list at zope-owner@zope.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope digest..."
Today's Topics:
1. Re: Help in deciding approach to Web App (Fernando Martins) 2. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 3. Re: Help in deciding approach to Web App (Fernando Martins) 4. Re: Help in deciding approach to Web App (John Schinnerer) 5. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 6. Re: Help in deciding approach to Web App (Fernando Martins) 7. Re: Help in deciding approach to Web App (John Schinnerer) 8. Re: Help in deciding approach to Web App (Niels Dettenbach) 9. Re: Help in deciding approach to Web App (Fernando) 10. Re: Help in deciding approach to Web App (Sareesh Sudhakaran) 11. Re: Help in deciding approach to Web App (Niels Dettenbach)
----------------------------------------------------------------------
Message: 1 Date: Sun, 04 Dec 2011 13:28:36 +0100 From: Fernando Martins <fernando@cmartins.nl> To: Sareesh Sudhakaran <aysand@hotmail.com> Cc: zope@zope.org Subject: Re: [Zope] Help in deciding approach to Web App Message-ID: <4EDB6774.1050603@cmartins.nl> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/04/2011 09:52 AM, Sareesh Sudhakaran wrote:
Thanks Niels. Just to clarify: Does my particular instance fall under an OODBMS model or a RDBMS model (with ORM if necessary)?
Data modelling is a bit of an art and probably you could tackle your problem with any approach. I think the important is for you to figure out which model suits more your personality. No kidding.
I would personally start with the RDBMS approach considering only the information you provide. Also, you can easily use zope in combination with a RDBMS. When you read the book, beware that zope has been changing from a "through the web" approach, to a typical file system based approach, which is a loss, but it seems to be what suits the needs of the zope developers.
The approach I use is:
zpt page -> (one) Python Script -> (some) ZSQL Methods -> MySQL
The zpt defines the layout of the pages, the ZSQL Methods retrieve the data needed and the Python script massages the data to make it suitable for the ZPT page. Or the other way around, from user input in a form to storage in the database.
The advantage of the relational approach is that it is a very well understood model and although different people will still come to different models there are sufficient objective guidelines out there (e.g., the normalization rules, and then criteria for when to denormalise) to help you along. Furthermore, there are lots of people in db-related forums that can help you.
Also, RDBMS provides you with a "standard" query language, SQL, which plenty of systems and tools can use. In general, RDBMS gives you the safest approach to keep your data and not loose it when you need to migrate either the front-end or the back-end. This language is very powerful and can avoid you a lot of low level programming.
However, plenty of people can not deal well with SQL because it follows a paradigm so different from the classic imperative programming. With SQL, you specify the "what", with the other languages you specify the "how". The advantage of the "what" is that you can do a lot of data processing in a few lines of code. The problem with the "what" is that because you don't know the "how" of it, you feel you don't have control and you are led to say the language is "obscure" or "unreadable".
However, even if you are not comfortable with the "what" (you have to try to know), you can still rely on an library like SQLAlchemy to keep you a bit in the comfort zone of the "how". So instead of learning SQL, you need to learn the API of a specific library. Your choice. I recommend the first by far.
The real main issue with Relational is that it is a highly structured data model. It allows you to keep high quality data but if you don't get it right soon enough in the development cycle, some later changes can have a huge impact in the application, requiring rewrites. Furthermore, it works the best when you have many objects with the same properties. If you have many entities all different from each other (the tools in your case, maybe), then maybe a OODBMS might be better. But here, there is no standard language, or standard whatever. Perosnally, I would avoid as much as possible to put data in something like ZODB (I use it merely to store and manage the application).
The problem with your specific case is that it does not seem to be a typical case of books and authors, which might be a risk for someone without experience. The issue "Tool A might have only three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to 2000", is indeed tricky. I suspect in general the needs of your system will be too specific to be able to rely only on SQL queries. You would need to put a lot of intelligence in the data (really highly structured) and it might become unmanageable or not scalable.
I guess you will need to put a lot of intelligence in the Python Script. So, the ZSQL retrieves the relevant tool data and then makes the tool choice. The knowledge of the meaning of the attributes is maintained in programming.
I should say I am not totally sure the Python Script is the best approach here, in terms of management facilities. But Python is surely a very good language due to its readability. However, you might need to use External methods or a more typical file-system based Python approach.
Or maybe you actually need to create a Domain Specific Language to encode the intelligence needed for your tool selection process. If your python code becomes repetitive, with patterns showing up, then a DSL might be a good approach, but this might be too much engineering for you at this stage. It looks like you are in a typical CIM scenario and I remember handling a similar problem 20 years ago. I vaguely remember at that time to use custom graph structures in C and the the intelligence was coded in Lisp/Scheme. So, there is a big range of solutions to try out :)
If you have time, then the simple approach
zpt page -> (one) Python Script -> (some) ZSQL Methods -> MySQL database
might be a good starting point. You should not need to spend much time to implement a prototype using this approach. In the worse case scenario it helps you understand better your problem and what could be a better approach with little investment. Essentially you try the classical approach and if it does not work well, either you are doing something wrong, or you have a better understanding of your needs and where to go.
Good luck, Fernando
On 12/05/2011 03:12 PM, Sareesh Sudhakaran wrote:
Hi John and Fernando Intuitively I feel that my project fits in with an Object DB, which is why I have spent a lot of time trying to understand its methodology. But now I'm more confused than ever.
Sareesh, could you be more specific about what confuses you? You have several routes, you need to give proper consideration to those routes. Maybe it would also help us if you clarify what is your skillset and experience in software development. Also, is your problem a CIM one? see http://en.wikipedia.org/wiki/Computer-integrated_manufacturing and specifically the key challenge listed over there. I have the impression you might be underestimating the problem. Finally, do you already have information about the tools in some electronic format? And what about the rules to choose tools? Is there already some computer based solution to help with the current problem? Please keep in mind that OOP and Object DB is not the same thing. You can work with objects in Python and never rely on OODB. I have serious doubts about using ZODB at your stage because AFAIK, creating custom objects requires the development of zope Products. Note that the zope book does not teach you about creating custom objects in the ZODB. You need another whole book for that. And the combination RDB and ZODB suggested by Neils/John seems too complicated as a start. I think you have a high learning curve ahead of you if have to learn to create Zope Packages to put objects in ZODB. But maybe there are simpler ways that I am not aware of. I'm sure OOP in Python and RDB is a good option. ZODB itself, I'm not so sure. Maybe others can enlighten you better here. It appears to me you don't have much experience and it looks like there is a long evolutionary project ahead of you. For these reasons, I would highly recommend Python. BTW, I never recommended and I do not recommend C/C++ for your needs, I just mentioned that I used it for a similar purpose many years ago. I would recommend you to do some programming in Python just to read some tool data from a text file, create some objects and try to do some tool selection where the output is merely done with print. Then you can upgrade to use MySQL to store your tool data and then you can decide if you go the Zope or the PHP route. Keep in mind that RDBs are a huge standard with many people and tools around it, whereas ZODB is very much a small niche in comparison. That should also weigh in your criteria. Regards, Fernando
Hi Fernando, I have experience in Pascal and C - but from 10 years ago and only in college capacity. But I've done some medium size projects in both (about 8000 to 10,000 lines each). Lately, my experience is limited to HTML/CSS and a tiny bit of Actionscript (for my flash websites). I have no OOP experience (C++). I have downloaded Python and PHP and have used both with Komodo Edit IDE, side by side, and have realized I would ideally want to program in Python. But I'm okay with PHP also - which means my choice of programming language depends on my choice of DB. Also, PHP has OOP 'capabilities' whatever that means - so maybe I can still use it like Python to a certain extent. I want to learn the least number of programs, which is why I had given myself three options:1. PHP + mySQL - the path of least resistance if an Object DB is not required. [I have no idea how to use Python with mySQL and the advice from googling is too confusing]2. Doctrine + PHP + mySQL or Django - for ORM with RDB 3. Bluebream for Object DB (I've found a couple of hosting providers who will let me install Zope on their VPS plans - so I'm okay with that) Can you point me to a resource for Python and mySQL? I've bought 'Dive into Python' but it has no reference on how to use it with mySQL. If my current hosting provider supports Python and mySQL, can I make it work? They won't let me install anything on the server side though, so I can't use any modules that aren't there already. Coming back to my particular scenario: No, it's not a CIM problem, but it does share the same level of complexity and hierarchy. There is no computer based solution that can be used - I'd researched that first. My app is purely software based for now. I already have information on the tools - but I have to organize them to suit the logic I'm going to use. I've spent the last two weeks collecting data in Excel, and this exercise is what started the confusion and my subsequent 'discovery' of the concept of Object Databases. I'll try to make my issue clearer. Let's say I want to compare the performance of two light bulbs, within a Building Management System (Lighting Component). If I use two CFL bulbs from two manufacturers - e.g. Philips and GE, they have slightly 'mis-matching' specifications. The possible scenarios:1. As marketing gimmicks, manufacturers might use different standards to test their bulbs, and maybe the same variable on paper (say lux, voltage, whatever) means two different things. Also, some manufacturers will include irrelevant data but I cannot discard it. As the 'expert' it is my job to make sense of the specifications and enter the data to use in the logic. However, my own standards might change in the future - either due to error or better methodology, etc. 2. One bulb might have a dimmer that has only two stops (similar to the rpm example) and the other bulb might have a continuous dimmer over a variable voltage. How do I input this information in a database? Other variables might have similar issues - like the first bulb can only operate strictly at 110/240V while the other can go from 50 to 300 or maybe it's only 240V. Etc. This issue exists in most tools, and is not a one-off problem.3. What happens when I suddenly decide to add 'different' tools? Instead of comparing CFLs, I now have to add a tungsten or an LED bulb and compare it against a CFL. The standards are completely different, and the logic is easy.4. Once a bulb is manufactured its specifications are set. But for complex machinery, there might be firmware updates that change a lot of variables. For each update, I have to create a new tool in the database - but I'll be repeating a lot of data. What if a manufacturer has the habit of releasing updates every month?5. Even on old tools, I might 'discover' new data - e.g., the materials used in a bulb might contribute towards toxicity or environmental pollution, and is now an important factor to consider - so I'll have to update a tool to add this new feature.6. My logic will have to pull data from any database - e.g. to find the best energy saving path in a building many different kinds of electric devices have to be considered. The total number of tools right now is only around 500 (<1000), and it will always remain less than 10x this amount (at least in the foreseeable future). However, the relationships between these tools is many to many. I'm not sure whether this complexity has to be shared by the database or is it just a problem for the logic.7. Some tools are manufactured products, and their data will not change 99.9% of the time (unless it's point 5 above). However, some tools are software based, and its functioning can be affected by many features - e.g. changing the RAM/HDD/CPU etc might speed up or slow down a piece of software. The variables for this kind of tool can change - the data is not constant in this case.8. Last but not least, if my app is to truly succeed, it must reach the capability to marry disjointed tools into seamless workflows. If I want to cook a recipe, the app should be able to tell me which ingredients to use, which manufacturers to buy from, the quantity and proportion, how to slice and dice, which way to cook it...etc. The app is an expert system. The end user is a layman who needs to find the best workflow without having to think about it. I feel like the layman who needs my own expert system! So: Do I need ZODB or am I going to be okay with mySQL? My confusion is restricted to Object DB vs RDB vs RDB+ORM. Among all the aspects of the project, this is the most boring and laborious to me, and I want to get it right the first time. I am confident I can make the logic work (the fun part), but I don't know how to manage the data (the boring part). Actually I like your suggestion, and I will code my project in PHP (or Python if I can find a way to use it with mySQL) using text files. I will use mySQL to start adding the data for the prototype. Hopefully things will work out! sareesh Date: Tue, 6 Dec 2011 00:14:25 +0100 From: fernando@cmartins.nl To: aysand@hotmail.com CC: zope@zope.org Subject: Re: [Zope] Zope Digest, Vol 91, Issue 2 On 12/05/2011 03:12 PM, Sareesh Sudhakaran wrote: Hi John and Fernando Intuitively I feel that my project fits in with an Object DB, which is why I have spent a lot of time trying to understand its methodology. But now I'm more confused than ever. Sareesh, could you be more specific about what confuses you? You have several routes, you need to give proper consideration to those routes. Maybe it would also help us if you clarify what is your skillset and experience in software development. Also, is your problem a CIM one? see http://en.wikipedia.org/wiki/Computer-integrated_manufacturing and specifically the key challenge listed over there. I have the impression you might be underestimating the problem. Finally, do you already have information about the tools in some electronic format? And what about the rules to choose tools? Is there already some computer based solution to help with the current problem? Please keep in mind that OOP and Object DB is not the same thing. You can work with objects in Python and never rely on OODB. I have serious doubts about using ZODB at your stage because AFAIK, creating custom objects requires the development of zope Products. Note that the zope book does not teach you about creating custom objects in the ZODB. You need another whole book for that. And the combination RDB and ZODB suggested by Neils/John seems too complicated as a start. I think you have a high learning curve ahead of you if have to learn to create Zope Packages to put objects in ZODB. But maybe there are simpler ways that I am not aware of. I'm sure OOP in Python and RDB is a good option. ZODB itself, I'm not so sure. Maybe others can enlighten you better here. It appears to me you don't have much experience and it looks like there is a long evolutionary project ahead of you. For these reasons, I would highly recommend Python. BTW, I never recommended and I do not recommend C/C++ for your needs, I just mentioned that I used it for a similar purpose many years ago. I would recommend you to do some programming in Python just to read some tool data from a text file, create some objects and try to do some tool selection where the output is merely done with print. Then you can upgrade to use MySQL to store your tool data and then you can decide if you go the Zope or the PHP route. Keep in mind that RDBs are a huge standard with many people and tools around it, whereas ZODB is very much a small niche in comparison. That should also weigh in your criteria. Regards, Fernando
Aloha, On 12/05/2011 05:30 PM, Sareesh Sudhakaran wrote:
I have downloaded Python and PHP and have used both with Komodo Edit IDE, side by side, and have realized I would ideally want to program in Python. But I'm okay with PHP also - which means my choice of programming language depends on my choice of DB. Also, PHP has OOP 'capabilities' whatever that means - so maybe I can still use it like Python to a certain extent.
Google is php object oriented and you'll get plenty of somewhat relevant hits. In terms of true OO languages (like python, ruby, java...), this may be a most relevant link: http://michaelkimsal.com/blog/php-is-not-object-oriented/ And, what he is pointing out may not be a problem for you, if mostly procedural with some object capabilities is suitable for your needs. If you are using python to build a zope product, the ZODB is used automagically, you don't have to do anything special. To access MySQL DBs you have to add an appropriate zope product to handle queries. A search on zope with mysql ...or vice versa returns mostly IMO embarrassingly old hits, many from old.zope.org and five to ten years old. So either the old info is still valid, or there is a lack of current information on using zope with mysql (though it is said that it is easy - where are non-stale howtos/tutorials for those who don't already know how?).
Can you point me to a resource for Python and mySQL? I've bought 'Dive into Python' but it has no reference on how to use it with mySQL. If my current hosting provider supports Python and mySQL, can I make it work? They won't let me install anything on the server side though, so I can't use any modules that aren't there already.
Look for info/howtos on Python's DB-API and the MySQLdb module. For example: http://pypi.python.org/pypi/MySQL-python/ http://sourceforge.net/projects/mysql-python/ http://zetcode.com/databases/mysqlpythontutorial/ http://www.devshed.com/c/a/Python/MySQL-Connectivity-With-Python/ ...though sounds like you can't add such modules on your current provider's server if not there already. Myself for a project of this complexity I would want much more control of my server options than it sounds like you have. A low-cost VPS (I use linode.com), or simply use localhost until I have my options sorted out. regards, John S. -- John Schinnerer - M.A., Whole Systems Design -------------------------------------------- - Eco-Living - Whole Systems Design Services People - Place - Learning - Integration john@eco-living.net http://eco-living.net
participants (3)
-
Fernando Martins -
John Schinnerer -
Sareesh Sudhakaran