# Abstract models & inheritance
**URL:** https://forum.djangoproject.com/t/abstract-models-inheritance/5289
**Category:** Using Django
**Created:** [November 19, 2020, 4:49pm UTC](https://forum.djangoproject.com/t/abstract-models-inheritance/5289 "2020-11-19T16:49:06Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@LazerRaptor](https://forum.djangoproject.com/u/LazerRaptor)
#### Post date: [November 19, 2020, 4:49pm UTC](https://forum.djangoproject.com/t/abstract-models-inheritance/5289/1 "2020-11-19T16:49:06Z")
Hello, fellow Django developers! I need an advice.
I have a typical Product model with descendants (Book, Laptop etc) that hold product-specific fields. Currently, I am using django-polymorphic, but I keep running into opinion that multi-table inheritance is a messy business and should be avoided if possible (e.g. this: [https://jacobian.org/2010/nov/2/concrete-inheritance/](https://jacobian.org/2010/nov/2/concrete-inheritance/)). Besides that, I believe there is a rule that says something like “application level logic shouldn’t affect the way your data is stored”. And with multi-table inheritance it kinda does.
With that being said, I am not sure how to do this in a neat way, using abstract inheritance. Django-mptt to store our inheritance tree + contenttypes? Something along these lines?
I haven’t found packages that help to deal with abstract inheritance, even though it seems to be a common problem and a logical way to approach it. So maybe I am missing something?
To be honest, I am not sure if I should be concerned about it. I just keep coming back to it for some reason. Maybe I just need someone experienced in this problems to say some wise words that will calm my mind. Anyway, thank you in advance for answering.
---
### Author:  [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)
#### Post date: [November 19, 2020, 6:04pm UTC](https://forum.djangoproject.com/t/abstract-models-inheritance/5289/2 "2020-11-19T18:04:44Z")
``
This is a case of asking `X` number of people this question and getting `2X+3` number of opinions.
I agree that “application logic shouldn’t affect the way your data is stored” - however, that’s only half the picture.
The other half is that application logic _requirements_ **should** affect the way your data is stored. Data models themselves don’t exist in a vacuum. There’s a set of processing requirements that drive the data model.
As you’ve already identified, there are a number of different ways to structure that type of data. Your optimal choices are going to depend upon what you need to do with it.
You mentioned the basic idea of a `Product` having descendants such as `Book` and `Laptop`. The next step then is to identify, _within your system_, what is the difference between a Book and a Laptop? For example, if you’re creating an inventory system, there may not be any type of effective difference at all. They’re just “things” where you’re tracking attributes such as location or ownership. Or, you might be building a system where you’re calculating power requirements for electrical outlets. In those cases, a `Laptop` has very real differences from `Books` that matter for this.
Bottom line from my perspective then is that there is no pat answer. You need to look beyond the entities themselves to identify the function those entities will perform. It’s _that_ information that will best drive your data design.
``