Big python web framework project

Question

I need your advice to choose the Python Web Framework for developing a large project:

The database (Postgresql) will have at least 500 tables, most of which have a composite primary key, many restrictions, indexes and queries. About 1,500 views to get you started. The project belongs to the financial district. New requirements will appear.

Does ORM help?

Answer 1

Django is used by many large organizations (Washington Post, etc.) and can easily contact Postgresql. I use it quite often and without problems.

Answer 2

Yes. ORM is essential for mapping SQL material to objects.

You have three options.

• Use another ORM

• Create your own.

• Try executing low-level SQL queries and select the required fields from the result set. It is - in fact - a kind of ORM with mappings scattered across all applications. It can be quickly executed and easily developed, but it is a nightmare for service.

If you design tables first, any ORM will be painful. For example, a “composite primary key” is usually a bad idea, and with ORM it is almost always a bad idea. You will need a surrogate primary key. Then you can have all the composite keys with the desired indexes. They simply will not be "primary."

If you first design objects, then create tables that will implement the objects, ORM will be nice, simple, and quick to start.

Answer 3

Since most of your tables have composite primary keys, you will need an ORM that supports this functionality. Django, by default, ORM does not support composite primary keys. SQLAlchemy has this support ( http://www.sqlalchemy.org/features.html ).

The TurboGears platform uses SQLAlchemy as the default ORM. Pylons also allows you to use SQLAlchemy.

There are also ways to force Django to use SQLAlchemy, although I have not tried them myself. I prefer to use Django myself, but given your needs, I would go with Pylons or TurboGears, rather than using the ORF boot in the system.

Answer 4

For such terrible complexity at the data level as 500 tables with 1,500 views, unlike most of the answers, I personally would prefer to stick with SQL (PostgreSQL offers a really great implementation, especially in the new version 8.4, which you really should lobby if you have a chance ); the only ORM that I [reluctantly] accept is SQLAlchemy (one of the few ORBs that I really don't mind), but the main added value is portability for different DBMSs: if you are committed to only one and in the project you will be better than then, then my personal opinion is that any ORM is just an overhead, since the developers of the data access level will need a deep knowledge of a particular DBMS for scanning in accordance with acceptable performance).

Choosing "raw psycopg2" or SQLAlchemy as the technology for my data access level would exclude Django (which in my experience only works with its own ORM), but such a database complexity is not suitable for the project, IMNSHO). I would go with Werkzeug, personally, as the basis most suitable for very complex projects requiring ridiculous flexibility and power - although Pylons and Turbogears 2 on top of it may be acceptable as failure if the team just doesn’t ”do you have experience with web applications and the skill required to create truly beautiful music with a flexible structure, such as Werkzeug.

Last but not least, I heavily lobbied Dojo for the presentation layer on the client — a rich and highly structured Javascript structure that offers superbly designed features for “local data”, host access, and optimized for the best that each of several browsers (and plugins such as Gears), as well as advanced user interface functionality, seem most likely to ease the heavy development burden for the core team (in fact, I would highly recommend let's look at the actually RESTful interface on the server side and delegate all the presentation work to Dojo on the client - see this site for more, except that I will think of JSON rather than XML as the preferred exchange format). But I readily agree to learn much less about the user interface side than about the back ends, business logic, and overall architecture, so take the last paragraph for what it costs! -)

Answer 5

Depending on what you want to do, you actually have several possible frameworks:

[Django] Big, strong (to the limit of the python framework), and senior in the race. Used by several "large" sites around the world ([Django sites]). However, this is a bit overkill for almost everything and with an outdated coding approach.

[Turbogears] is a recent structure based on Pylons. I don’t know much about this, but received a lot of good reviews from friends who tried it.

[Pylons] (which Turbogears2 is based on). Often seen in "PHP Python", it allows you to develop very quickly from scratch. Even if this may seem inappropriate for large projects, it is often faster and easier.

The last option is [Zope] (with or without Plone), but Plone is a way to slow down, and the Zope learning curve is too long (not to mention replacing ZODB with an SQL connector), therefore, t know the scope yet, just forget about it .

And yes, ORM seems mandatory for a project of this size. For Django, you have to handle the migration to your database models (I don’t know how difficult it is to connect SQLAlchemy to Django). For turbo engines and pylons, the most appropriate solution is [SQLAlchemy], which is actually the most complete (and upstream) ORM for python. For zope ... well, nevermind

And last but not least, I’m not sure that you are starting a good foundation for your project. 500 tables on any python framework will scare me to death. A boring but tough language like java (hibernate + spring + tapestry or so) seems more appropriate.

Answer 6

I would absolutely recommend Repoze.bfg with SQLAlchemy for what you described. Now I have done projects in Django, TurboGears 1, TurboGears 2, Pylons and worked on pure Zope3. BFG is far from all the frameworks that are most designed to accommodate a project that grows in a way that you would not expect at the beginning, but much easier and truncated than Grok or Zope 3. In addition, documents are the best technical documents of all them, not the simplest ones, but those that answer the difficult questions that you will encounter. I am currently doing the same when we are rebuilding a lot of legacy databases into a new web application and we use BFG, some Pylons, Zope 3 adapters, Genshi for templates, SQLAlchemy and Dojo for the front end. We could not be happier with BFG, and it works great. The BFGs classes, as representations that are actually multi-user multiplexers, are absolutely ideal for being able to override only certain bits for certain domain resources. And the complete absence of magic globals anywhere allows us to test and package the simplest ones that we had with any infrastructure.

YMMV!

Answer 7

New requirements expected.

So you really need an infrastructure that allows you to quickly adapt to changing specifications.

From personal experience, I can only discuss django, which is great, because it allows you to get up and work quickly.

If you stick to your ORM, you will have a fairly simple time when your models will be instantiated and connected in useful ways. You will need to familiarize yourself with the database migration tool because Django does not have a built-in module. dmigrations seems to be the leading tool for this.

Another choice for ORM is SQLAlchemy , which looks a little more mature out of the box.