1

The simplified scenario first:

  • Merchants have products

  • Merchants have categories

  • Products have subcategories

  • A merchant's products' categories must have the merchant's category as the parent category

This is modelled using the RDBMS approach. I'm using Postgres for my database and Django as the web framework. We have features such as enabling/disabling a product/category/merchant. The effects of these must cascade and the data should remain consistent. Where should this be handled ? I can have triggers in my DB to enforce this, or use methods/signals like pre save/post save, pre init/post init in my Django models to do the same. Which is more appropriate. I'm more comfortable with python than SQL, and believe that doing it via Django models makes it more modifiable, since In my company the requirements are prone to frequent and sudden changes.

madhukar93
  • 507
  • 5
  • 23

1 Answers1

1

If it's indeed about data integrity, do it within Postgres, it will be much much easier to stay consistent when your data model expands.

(I've grown an application from about 10 to about 70 tables, the parts of the data model which where ensured by DB schema have been clean ever since. The parts which tried to maintain a consistency allegedly on a "higher" level screwed up now and then)

If it's about the behaviour of the application, do it in django.

knitti
  • 6,817
  • 31
  • 42
  • This is so opinion based. – Wtower May 20 '15 at 09:24
  • 1
    I agree in part. It is also about best practices in designing your data model – knitti May 20 '15 at 11:16
  • 1
    Why did you do it for parts of the data model only. If you had decided to let the dbms handle it, why did you not stick with it ? – madhukar93 May 20 '15 at 12:26
  • 1
    All of these played a role: 1) design by committee 2) the model was in hindsight not well enough thought through 3) soft-coding antipattern – knitti May 20 '15 at 12:36
  • @ knitti & @EagerNoob: "If it's about the behaviour of the application" is maybe misleading. Behaviour is parameterized/affected by the database so better would be, if it's*only* about the behaviour of the application". But best is, the/a database can and should contain as much application session control flow and session state as practical. (Ie *proper* soft-coding.) – philipxy Aug 03 '15 at 22:38