Home/ Questions/Q 106713
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T01:38:24+00:00

I’m looking for some quick thoughts about a business application I am looking to

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 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

    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.

    • 0