Develop Reference

Additional auth tables when extending Djangos AbstractUser

I am new to Django and discovered something I do not quite understand: I extended the default user class of django auth with a custom field to look like this:
class User(AbstractUser):
business_entity = models.ForeignKey('BusinessEntity', on_delete=models.PROTECT)
In the settings file, I also added the needed AUTH_USER_MODEL = 'core.User' since my new user model is located in the core app. Works fine so far.
After applying all migrations (even after wiping the database and reapplying), I, however, am left with a few additional tables that I did not want to create and that seem not to be used by Django's auth app:
Tables created after migration
As you can see there are from the auth app: auth_group, auth_group_permissions and auth_permissions as well as from core app: core_user_groups, core_user_user_permissions.
I searched quite a while - maybe with the wrong keywords? - but I am not able to figure out if I need all those tables and - especially - what the additional core tables are used for. Can you shed some light on this?
Thank you very much!

I am quite sure those are the tables that django uses to store permissions and you shouldn't delete them. For instance, when you make a superuser (an admin), django knows that only he/she can access the /admin page. This knowledge comes from permissions stored in those tables.
If you are not using those tables chances are they only occupy a minimum amount of space (according to the link below, only 4 permissions are added by default) and you shouldn't worry about them. That said, knowing how to manage permissions well can help a lot depending on your project.
More info about permissions can be seen here.

Editing models and extending database structure in Saleor

I recently forked Saleor 2.9 for a web app I am building for an art gallery that wants to display their products for sale as well as give their artists some publicity. I want to be able to have a bunch of cards (like "our team" components) that pull data from an Artists table on the back-end that stores information about the artists' names, emails, origins, etc, and then display it on the front-end. I am struggling to see how to modify the models/DB to create a new "Artists" table with name, email, info, and then to create a manyToMany-like relationship with the products I've populated in the DC, giving the products a "created by" attribute. There are tons of models files throughout the /dashboard directory, and even when I make changes to the core models to create an artist class, I don't know how to get it to show on the dashboard so artists can be created/modified from there.
I would like to make it so that the client (non-technical) can add artists and have them show up on the artists page I will make, somewhat like products show up on their pages (but obviously I cannot create a new category "Artist" as artists cannot have prices or shipping as they are people; and there are other attributes I would want like email that a product cannot have, either. They are also different to staff on the website, so I cannot use the "staff management" functionality.)
I looked at this question but Saleor structure has changed since then, and that was a relatively minor attributal change to an existing class (User) as opposed to the creation and integration of a new class. I'm surprised that despite extensively searching for anything on how to do something as straightforward as create a new model there is little documentation and discussion online; I must be missing something.
Please help :) Thank you!

The django way to create new models, (and Saleor´s backend is django based) is:
You should create a new app on your store backend (the django part of saleor) with:
$ python manage.py startapp artist
Create your Artist model, with all the fields you want such as email, etc... in the file: artist/models.py.
Modify the Product model in the file product/models.py by importing the Artist models and adding a ForeignKey (for example) relationship to it.
Register the new artist app in your settings.py's "INSTALLED_APPS".
Run python manage.py makemigrations... (Check they include your changes to models)
Run python manage.py migrate.
That should be it. 'less I`m forgeting something, in which case, please post back when you have moved forward with this.
Notes:
You may want to back up your DB first.
Also when applying these migrations, django will ask you for a placeholder value for products which where in your DB before Product had an Artist field.
References:
django models
django migrations

Database first Django models

In ASP.NET there is entity framework or something called "database first," where entities are generated from an existing database. Is there something similar for Django?
I usually work with a pre-existing database that I need to create a backend (and subsequently a front end) for. Some of these relational databases have many tables and relations so manually writing models isn't a good idea. I've scoured Google for solutions but have come up relatively empty handed.

You can use the information on this link.
python manage.py inspectdb > models.py
https://docs.djangoproject.com/en/3.0/howto/legacy-databases/
It depends on your database, but I've worked with it and is good.

The default in Django is a Code First-type approach where the Django framework engine creates a Db for you based on your models and uses migrations to update the Db with model changes (like Code First).
https://docs.djangoproject.com/en/1.11/intro/tutorial02/
What you're describing sounds like a Database First approach in the .Net world.
Integrating Django with a legacy database:
https://docs.djangoproject.com/en/1.11/howto/legacy-databases/

to add new classes in models.py without modifying the data associated with existing model classes in django

I want to add some set of classes to models.py file in the django app which already has some classes created in that synchronized and contain data in each one of them in the database (created in mysql).
when I add new classes and type command
python manage.py makemigrations app-label//(using django 1.8 version)
it shows the
creating table names ...
but I when I run :
python manage.py migrate
it shows ...
table "access_log" already exists
I have tried many of the stack overflow links but nothing helped me. Like few of them are :
link 1 -stack-overflow
link 2 -stack-overflow
link 3 -stack-overflow
Also my exiting tables with data in database have attribute managed = false. Will that affect ?
Why is this happening?
Please help, I am not much well-versed with django.

Database Tables not defined in DJANGO models

Is it fine not to define table stucture in models.py...I mean we are using
cursor.execute('some query')
so its okay not to make something like this :
def tblNew(models.Model)
col1 = models.CharField(max_length=2)
Thanks for guidance, Im a newbie in django.

You CAN create database tables directly in postgresql But you'd have to create models.py files later because otherwise you will be missing out on several things. If you have pre-existing database, then you have django-admin.py command to pick them up for you (https://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb)
ORM. It makes alot of things easyer. Writing sql in views? Why would that be good? Because that is what you get if you do not use ORM at all. And while i do have sql in some of my views, it only exists there because django lacks some features like language collation specific sorting. But otherwise writing sql in views hampers readability.
You can't use database migrations. South (http://south.aeracode.org/) is one awesome project that most big django projects use. In fact i think it was most used django project in some apps poll. Django 1.7 will provide the migrations too, but you will need to declare models im models.py for that. What you loose if you do not use database migrations - SANITY. I do not exaggerate here. Keeping track of database changes in development and prelive/live servers is nightmare otherwise.
Also is not using django ORM in some places (not declaring models) kind of strange, while you will definately use django models and ORM elsewhere - or will you stop using django authentication, sessions and site logic also? All those use django ORM...