Какво ще кажете, ако можете да организирате обектите на базата данни (например таблици и изгледи) в пространства от имена според ролите им в системата?
В тази статия ще видим правилния начин за работа със схемите на PostgreSQL в Django и някои малки съвети за Django модели и Python.

Схема

Също известен като пространство от имена, схемата е тип обект на база данни, чиято цел е да бъде йерархичен организационен слой, който е точно под база данни.
В PostgreSQL „public“ е схемата по подразбиране, но можете да създадете своя собствена пространства от имена за организиране на други видове обекти като таблици, изгледи, функции и т.н.

Йерархия на обекти в базата данни

- Сървър |- Инстанция на PostgreSQL (порт 5432 по подразбиране) |- Роля (Потребители и групи) |- Пространство на таблици |- База данни |- Тригер |- Разширение |- Език |- Схема |- Таблица |- Изглед |- Материализирано Преглед |- Последователност |- Функция |- Процедура

За нашата лаборатория

Това е проста лаборатория с Django във виртуална среда (с virtualenv) и PostgreSQL, инсталиран в localhost.

Python 3.8
Django 3.0
PostgreSQL 12

Трябва да работи с много по-стари версии 🙂

Кодове

> SQL (psql);
$ shell (Linux, FreeBSD, Unix*);
>>> Обвивка на Python.

Практика

PostgreSQL

Структурата на базата данни е първото нещо, което ще направим.

Създаване на потребител на база данни за приложението;
Създаване на база данни;
Създаване на схема;
Създаване на таблица

Нека създадем собствен пример във вградения инструмент за команден ред на psql:

$ psql

Създаване на потребителско приложение:

СЪЗДАВАНЕ НА РОЛЯ user_test КРИПИРАНА ПАРОЛА '123' ВХОД;

Ролята на базата данни е създадена с криптирана парола и атрибут за вход (потребител).

Създаване на база данни за тестове:

> СЪЗДАВАНЕ НА БАЗА ДАННИ db_test OWNER user_test;

Базата данни е собственост на “user_test”.

Свържете се с него като потребител „user_test“:

> \c db_test user_test

Вътре в обвивката на psql \c потребителско име на базата данни.

Създаване на схема:

> СЪЗДАВАНЕ НА СХЕМА ns_hr;

Пространството от имена за нашия пример е готово!

Показване на всички схеми, които не са каталози:

> SELECTnspname AS namespaceFROM pg_catalog.pg_namespaceWHERE nspname !~ '(^pg_|information_schema)';

Изход:

namespace ----------- public ns_hr

Забележете, че се появява пространството от имена по подразбиране (публично) и ns_hr, създадени за нашата лаборатория.

Създаване на таблица в схема ns_hr:

> CREATE TABLE ns_hr.tb_person( id_ сериен първичен ключ, текстът на името не е нулев, текстът на фамилното име не е нулев);

Проста таблица...

Натиснете <Ctrl> + D за да излезете.

Django

Време е да кодирате в Python! 😀

Виртуална среда;
Инсталиране на модули на Python;
Създаване и конфигуриране на Django проект;
Създаване на приложение Django;
Създаване на Django модел;
Миграции;
Тестове в обвивка;

Създаване на виртуална среда:

$ virtualenv -p `кой python3.8` django

Абсолютният път на двоичния файл на Python 3.8 беше посочен като интерпретатор на Python на тази среда.

Достъп до директорията на средата и я активирайте:

$ cd django &&източник bin/активиране

Подканата ви се промени, започва от „(django)“, което показва, че вашата виртуална среда е активирана.

Инсталирайте необходими модули за нашите тестове:

$ pip install django psycopg2-binary configobj ipython

Съответно:Django уеб рамка, PostgreSQL драйвер, четец на конфигурационни файлове и подобрена интерактивна обвивка.

Създаване на нов проект на Django:

$ django-admin startproject my_project

Преименувайте директорията на проекта на src:

$ mv my_project src

Това е за улесняване на йерархията на директориите и няма да повлияе на резултатите. Това е, защото има една и съща директория, което може да причини известно объркване...

Създаване на конфигурационен файл на база данни:

$ cat < src/my_project/db.confDB_HOST ='localhost'DB_NAME ='db_test'DB_USER ='user_test'DB_PASSWORD ='123'DB_PORT =5432EOF

Тук създадохме отделен конфигурационен файл за връзката с базата данни.

Редактирайте основния конфигурационен файл на проекта:

$ vim src/my_project/settings.py

импортиране на os от configobj импортиране на ConfigObj

Под импортираните добавете ред, който носи клас ConfigObj.

# База данни# https://docs.djangoproject.com/en/2.2/ref/settings/#databases# Конфигурационен файл на база данни locationDB_CONF_FILE =f'{BASE_DIR}/my_project/db.conf'# Прочетете конфигурациите от fileDB_CONFIG =ConfigObj(DB_CONF_FILE)# Параметри на свързване към базата данниDB_HOST =DB_CONFIG['DB_HOST']DB_NAME =DB_CONFIG['DB_NAME']DB_USER =DB_CONFIG['DB_USER']DB_PASSWORD =DB_CONFIG['DB_DATA_PASSPORT] =['DB_PASSPORT] { 'default':{ 'ENGINE':'django.db.backends.postgresql', 'NAME':DB_NAME, 'USER':DB_USER, 'PASSWORD':DB_PASSWORD, 'HOST':DB_HOST, 'PORT':DB_PORT, } }

Променете „сесията“ на базата данни, както по-горе.

Създаване на символна връзка за manage.py:

$ ln -s `pwd`/src/manage.py `pwd`/bin/manage.py

За да улесним работата си, създадохме символична връзка към manage.py в директорията bin, която е в нашия $PATH.

Стартирайте виртуален уеб сървър:

$ manage.py runserver 0.0.0.0:8000

Тествайте във вашия браузър:http://localhost:8000 и след това + C за прекратяване.

Достъп до директорията на проекта:

$ cd src

Нека проверим файловете в текущата директория:

$ дърво .

Изход:

.├── manage.py└── my_project ├── db.conf ├── __init__.py ├── __pycache__ │ ├── __init__.cpython-38.pyc настройки │ ├── __init__.py ├── __pycache__ │ ├── __init__.cpython-38.pyc │ │ ├─th─ on .pyc │ ├── urls.cpython-38.pyc │ └── wsgi.cpython-38.pyc ├── settings.py ├── urls.py └── wsgi.py

Избройте съдържанието на текущата директория в дървовиден формат.
Тук виждаме всички файлове в проекта.

Първа миграция за метаданни на Django:

$ manage.py мигриране

Създаване на супер потребител на Django:

$ manage.py createsuperuser

Създайте приложение:

$ manage.py startapp human_resource

Редактирайте settings.py, за да добавите ново приложение:

$ vim my_project/settings.py

# Application definitionINSTALLED_APPS =[ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django .contrib.staticfiles', # Персонализирани приложения 'human_resource',]

Страхотен трик на Django:можете да използвате директория models вместо файл models.py.
Но трябва да създадете dunder init файл (__init__.py) вътре в директорията models.
Да тръгваме! P>

Създаване на директория с модели в директорията на приложението:

$ mkdir human_resource/models

Премахнете файла models.py:

$ rm -f human_resource/models.py

Създаване на модел:

$ vim human_resource/models/hr.py

от django.db.models импортирайте AutoField от django.db.models импортирайте Model от django.db.models импортирайте TextFieldclass Person(Model):''' Person Model namespace:ns_hr Table:tb_person ''' id_ =AutoField(db_column='id_', name='id', primary_key=True,) name =TextField(db_column='name', name='name',) фамилия =TextField(db_column='фамилия', name='фамилия',) def __str__(self):return f'{self.name} {self.surname}' class Meta:db_table ='ns_hr"."tb_person' # 'schema"."object' verbose_name_plural ='Person'

За да се насладите на предимствата на PostgreSQL схемите, във вашия модел, във вътрешния клас Meta, към стойността на атрибута „db_table“, трябва да поставите точка, която разделя пространството от имена и обекта между кавички.

'schema"."object'

Обектът може да бъде таблица или изглед, например...

Dunder init в директорията на моделите за влизане в сила на миграциите:

vim human_resource/models/__init__.py

от human_resource.models.hr import Person

Това е необходимо, за да може директорията models да работи като файл models.py.

(Не) Миграции:Моята база данни, моите правила!

Ние създаваме структурата на нашата база данни и никой ORM не трябва да го прави вместо нас!
Имаме силата!
Имаме силата!
Ние командваме!

Нашата база данни, нашите правила! 😉

Просто моделирайте вашата база данни със собствените си ръце и направете фалшива миграция на Django.
Защото само ние знаем как трябва да бъдат създадени обектите на базата данни 😉

Направете миграции за приложението human_resource:

$ manage.py makemigrations human_resource

Фалшива миграция:

$ manage.py migrate --fake

Нека проверим йерархията на директорията на приложението:

$ дърво човешки_ресурс/

human_resource/├── admin.py├── apps.py├── __init__.py├── миграции│ ├── 0001_initial.py│ ├── __init__.py│ ├── __init__.py│ ├── __init__.py│ └ca──__ 0001_initial.cpython-38.pyc│ └── __init__.cpython-38.pyc├── модели│ ├── hr.py│ ├── __init__.py│ └─│ └─│ └─│ ├─│ └─_│ ├─│ ├─│ ├─│ __├─ __─ .pyc│ └── __init__.cpython-38.pyc├── __pycache__│ ├── admin.cpython-38.pyc│ └── __init__.cpython-38.s.cpython-38.pyc│ изгледи. py

Django Shell (Ipython):

$ manage.py shell

>>> от human_resource.models.hr import Person>>> p =Лице(име='Лудвиг', фамилия='ван Бетовен')>>> print(p)

Изход:

Лудвиг ван Бетовен

>>> p.save() # Продължава в базата данни

Натиснете <Ctrl> + D за излизане!

Обвивка на базата данни (psql):

$ manage.py dbshell

Заявка за проверка дали данните са били вмъкнати от Django:

> ИЗБЕРЕТЕ ID_, име, фамилия ОТ ns_hr.tb_person;

Изход:

<пред> идентификатор | име | фамилия ----+--------+-------------- 1 | Лудвиг | ван Бетовен

Заключение

PostgreSQL е стабилна и мощна RDBMS с много функции, включително пространства от имена за нейните обекти.
Django е страхотна уеб рамка, която е много стабилна и също има много функции.
Така че можете извлечете по-доброто от двете, за да постигнете по-добри резултати и за да направите това, един от начините е да постигнете по-добра организация.
Организирането на обектите на вашата база данни в пространства от имена според ролите им ще донесе ползи за вас 😉

PostgreSQL схеми/пространства от имена с Django

Схема

Йерархия на обекти в базата данни

За нашата лаборатория

Практика

PostgreSQL

Django

(Не) Миграции:Моята база данни, моите правила!

Заключение