[Zope] Zope Digest, Vol 91, Issue 2

Tue Dec 6 03:30:29 UTC 2011

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 at cmartins.nl
To: aysand at hotmail.com
CC: zope at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/zope/attachments/20111206/717893b8/attachment.html>