On Sun, Dec 4, 2011 at 06:12, Sareesh Sudhakaran <ays...@hotmail.com> wrote:
> I have a personal project - a web application I wanted to develop - but I'm
> confused on which route to take. I am not under any time constraint.
Your case is complex and the answer is non-obvious. I think you will
have to try to see.
> The best I can describe it is as a kind of expert system (but not AI) that
> needs to find the best workflow for a process, given a set of initial and
> final parameters. E.g. a 'capsule' of data must pass through many 'tools' or
> 'environments' to reach a desired output - something like a very complicated
> car wash.
> Let's say there are many tools that can be used at various stages in the
> process. I have estimated there are at least 500 tools as of now, and it is
> bound to grow in the future as newer tools are introduced. Existing tools
> will also have version updates.
> Each tool, on average, has at least 100 properties that define the tool.
This kind of complexity and flexibility that your case has does lend
itself well to the ZODB. But it is by no means impossible to do in a
relational database. What you would need to do here if you did this in
SQL is to have one table for the tools, and one table for the
properties, and one table that for each tool and property has a value.
This might be a bit complex to use of you use an ORM, but it should be doable.
> problem of 'matching' the tools for analysis. E.g. Tool A might have only
> three fixed rpms - 100, 200 and 500, but Tool B might have rpms from 20 to
> 2000. I'm not sure how I can construct a database without spelling out each
> number, as in the example above.
Well, if you want to search for a specific RPM range it does get
complicated, because then you probably want to store the RPM values as
integers. And that means that you in the property table needs to have
several columns depending on the value type. If the property needs
text, you need to fetch it from the text column. If the property is an
integer you need to fetch it from the integer column. If the property
is a reference to another table, because it is a multi-select property
with a limited set, you need to fetch it from a column for that, which
in turn refers to another table with the actual values.
This *does* get very complex very quickly. Of course, the ZODB has few
> Will the app be better served with a relational DB like mySQL or an Object
> database? After a lot of research I've guessed that my particular case might
> be better served with Python and Zope/ZODB. But I might be wrong? Maybe
> PHP+mySQL or Django is a better fit?
First of all, find yourself a web-framework you like. Then use that.
Most likely, that framework is going to limit you to using SQL. There
are frameworks that don't specifically Pyramid integrates nicely with
ZODB and hence gives you a choice. Then I would simply try to see if
you are able to model the data in SQL at all, or if you dig yourself
into unholy complexity. That should not take more than a couple of
days of work to figure that out, if you concentrate on building a
database and filling it with real or realistic data. If you don't dig
yourself into a hole, the go with SQL, since that's what you know. If
you do, try to build the model with ZODB and see of that works better
The ZODB might very well be the right choice here. But note that Zope
is not. Zope was a trailblazer in the web framework world that's been
around for 15 years now, and has as a result made some choices which
turned out to not be the best ones in the long run, and accumulated a
lot of cruft. There is work on fixing this, but that will take time,
and the framework will be in a great flux during that time. As a
result, Zope is not currently a good choice if you start a project. As
languages go, Python rules. As web frameworks go, there are more
Python frameworks than you can shake a stick at. I'd recommend either
Django (because there are so many people using it, you will be able to
find help ) or Pyramid (because it's really cool and supports ZODB
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -