Is a PHP, Python, PostgreSQL design suitable for a business application? [closed]

Question

I'm looking for some quick thoughts about a business application I am looking to build. I'd like to separate the three layers of presentation, domain logic, and data using PHP, Python, and PostgreSQL, respectively. I would like to hear, possibly from other folks who have gone down this path before, if there are problems with this approach, if I am targeting the wrong tools, etc.

• I'm looking at PHP because it is widely used, fairly mature, and I can find ample people with skills in PHP interface design.

• I'm looking at Python because of the benefits of readable code, because I hear can find more Python programmers that also have subject-matter skills (in this case, finance), and it's an open source language. Plus, it seems easier to code with.

• I'm looking at PostgreSQL for the transaction-level features. MySQL is also an option here, but I don't need to debate this aspect.

This is not a web application, although I would like to utilize a browser for the user interface. This is more of an Enterprise Application, but for a small business with moderate numbers of users (maybe 5-10) and a modest number of daily transactions.

What is important is that we are able to upgrade the database or domain logic or interface separate from the other layers in the future.

I'm NOT looking for a buy vs. build debate, as that's a different discussion.

Thanks for any insight

Answer 1

Look at Django.

Python code. A template language that permits some of the same features as PHP -- slightly different syntax.

Model is divorced from view functions ("business rules") and divorced from presentation. This is enforced throughout Django.

One of the common questions is "why can't I do -- some crazy PHP-like thing -- in the Django template?" The answer is that presentation is not processing. Do your processing in the Django view functions. Render the results as HTML in the template.

Also, Django has an ORM layer to divorce you from petty SQL considerations. MySQL or PostgreSQL are more-or-less equivalent from within Django.

---

Edit

"Maturity" means a lot of things. You specifically mentioned skilled people as a sign of maturity.

Django is pure Python. If you can find Python people, they can learn Django in a few days. They just have to do the tutorials.

• A Django-powered site is usually Apache + some glue + Django. The glue can be mod_wsgi or mod_python or mod_fastcgi. You have to manage this configuration with some care because there are several moving parts. This, however, is the same Apache config problem you have with PHP -- nothing new here.

• A Django site has one or more Django server instances, each with a settings file, a URL mapping and any number of applications. Pure Python at this point.

• A Django application has URL mappings, model and views. All pure Python. Unit tested with the Django extensions to Python's own internal unittest framework.

• The model uses an ORM layer. This may, perhaps, be the single most confusing thing in Django. People sometimes design very odd models because they think either too high-level-uber-generic or they think too much in SQL. Django is a middle ground of mostly object-orientation with some SQL consideration. Get this, and you're unstoppable.

• A Django application may have templates, which are in their own template language. This would be about the only non-Python thing that's of much interest. You may want to add custom tags -- pure Python.

• You'll probably have JavaScript (also true for PHP and every other web application framework). Nothing new here.

• Since Django's admin application automatically handles basic CRUD processing, you don't have to write this. You are free to write all the transactional stuff you want. But you don't have to. This leads you to a very, very powerful hybrid.

  • You write a few complicated, critical transactions. Pure Python, BTW.

  • You don't write any of the dumb table-maintenance transactions. No code at all is superior to Python or PHP.

  • After you get your feet wet with the template engine and CSS's, you can tailor the admin interface to look like anything you want. This is HTML/CSS stuff, no Python or PHP.

Bottom line. Most of the skill set is Python. The ORM is -- syntactically -- Python, but requires some care in doing things simply and cleanly. The template is it's own language, but considerably simpler than PHP. The rest is SQL, Javascript, HTML, CSS, Apache and what-not.

---

Edit

Django Maturity

• See http://www.djangoproject.com/community/ for the number of active projects.

• Join http://groups.google.com/group/django-users for daily flood of emails from users.

The Django blog stretches back to '05, meaning they had years of solid experience before finally releasing 1.0 in September of '08. Development apparently began in '03.

Answer 2

I'm going to assume that by "business application" you mean a web application hosted in an intranet environment as opposed to some sort of SaaS application on the internet.

While you're in the process of architecting your application you need to consider the existing infrastructure and infrastructure support people of your employer/customer. Also, if the company is large enough to have things such as "approved software/hardware lists," you should be aware of those. Keep in mind that some elements of the list may be downright retarded. Don't let past mistakes dictate the architecture of your app, but in cases where they are reasonably sensible I would pick my battles and stick with your enterprise standard. This can be a real pain when you pick a development stack that really works best on Unix/Linux, and then someone tries to force onto a Windows server admined by someone who's never touched anything but ASP.NET applications.

Unless there is a particular PHP module that you intend to use that has no Python equivalent, I would drop PHP and use Django. If there is a compelling reason to use PHP, then I'd drop Python. I'm having difficulty imagining a scenario where you would want to use both at the same time.

As for PG versus MySQL, either works. Look at what you customer already has deployed, and if they have a bunch of one and little of another, pick that. If they have existing Oracle infrastructure you should consider using it. If they are an SQL Server shop...reconsider your stack and remember to pick your battles.