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!

Date: Tue, 6 Dec 2011 00:14:25 +0100
From: ferna...@cmartins.nl
To: ays...@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


    Sareesh, could you be more specific about what confuses you? You
    have several routes, you need to give proper consideration to those


    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


    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.




Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to