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
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
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 -