sql >> Databasteknik >  >> RDS >> PostgreSQL

PostgreSQL-scheman / namnutrymmen med Django

Vad sägs om om du kunde organisera dina databasobjekt (t.ex. tabeller och vyer) i namnutrymmen enligt dess roller i systemet?
I den här artikeln kommer vi att se det rätta sättet att hantera PostgreSQL-scheman i Django och några små tips om Django-modeller och Python.

Schema

Även känt som ett namnområde, är schema en typ av databasobjekt vars syfte är att vara ett hierarkiskt organisationslager som ligger precis under en databas.
På PostgreSQL är "public" standardschemat, men du kan skapa ditt eget namnrymder för att organisera andra snälla objekt såsom tabeller, vyer, funktioner och etc.

Databasobjekthierarki

- Server |- PostgreSQL-instans (Port 5432 som standard) |- Roll (användare och grupper) |- Tabellutrymme |- Databas |- Trigger |- Tillägg |- Språk |- Schema |- Tabell |- ​​Visa |- Materialiserad Visa |- Sekvens |- Funktion |- Procedur

Om vårt labb

Det är ett enkelt labb med Django i en virtuell miljö (med virtualenv) och PostgreSQL installerat i localhost.

  • Python 3.8
  • Django 3.0
  • PostgreSQL 12

Borde fungera med många äldre versioner 🙂

Koder

  • > SQL (psql);
  • $-skal (Linux, FreeBSD, Unix*);
  • >>> Python-skal.

Öva

  • PostgreSQL

Databasstrukturen är det första vi kommer att göra.

  • Skapa databasanvändare för programmet;
  • Skapa databas;
  • Skapa schema;
  • Skapa tabell

Låt oss skapa vårt eget exempel i psql inbyggda kommandoradsverktyg: 

$ psql

Skapa användarapplikation: 

CREATE ROLE user_test KRYPTAT LÖSENORD '123' LOGIN;

Databasrollen skapades med ett krypterat lösenord och inloggningsattribut (användare).

Skapa databas för tester: 

> SKAPA DATABAS db_test OWNER user_test;

Databasen ägs av "user_test".

Anslut till den som användare "user_test": 

> \c db_test user_test

Inuti psql-skalet \c databasens användarnamn.

Skapa ett schema: 

> SKAPA SCHEMA ns_hr;

Namnutrymmet för vårt exempel är klart!

Visa alla scheman som inte är kataloger: 

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

Utdata:

namnutrymme ---------- public ns_hr

Observera att standardnamnrymden (public) och ns_hr, skapad för vårt labb visas.

Skapa en tabell i ns_hr-schema: 

> SKAPA TABELL ns_hr.tb_person( id_ seriell primärnyckel, namntext inte null, efternamnstext inte null);

Ett enkelt bord...

Tryck på <Ctrl> + D för att avsluta.

  • Django

Det är dags att koda i Python! 😀

  • Virtuell miljö;
  • Installation av Python-moduler;
  • Skapa och konfigurera Django-projekt;
  • Skapa Django-app;
  • Skapa Django-modell;
  • Migreringar;
  • Tester i skal;

Skapa virtuell miljö: 

$ virtualenv -p `som python3.8` django

Den absoluta sökvägen för binär i Python 3.8 indikerades som Python-tolkare av denna miljö.

Öppna miljökatalogen och aktivera den:

$ cd django &&source bin/activate

Din uppmaning ändrades, började vid "(django)" vilket indikerar att din virtuella miljö var aktiverad.

Installera behovsmoduler för våra tester: 

$ pip installera django psycopg2-binär configobj ipython

Respektive:Django webbramverk, PostgreSQL-drivrutin, konfigurationsfilläsare och förbättrat interaktivt skal.

Skapa ett nytt Django-projekt: 

$ django-admin startproject my_project

Byt namn på katalogen för projektet till src: 

$ mv my_project src

Detta är för att underlätta kataloghierarkin och kommer inte att påverka resultaten. Det är för att den har en katalog med samma namn som kan orsaka viss förvirring...

Skapa databaskonfigurationsfil: 

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

Här skapade vi en separat konfigurationsfil för databasanslutningen.

Redigera huvudkonfigurationsfilen för projektet: 

$ vim src/my_project/settings.py

importera os från configobj import ConfigObj

Lägg till en rad under importerna som ger ConfigObj-klassen.

# Databas# https://docs.djangoproject.com/en/2.2/ref/settings/#databases# Databaskonfigurationsfil platsDB_CONF_FILE =f'{BASE_DIR}/my_project/db.conf'# Läs konfigurationerna från fileDB_CONFIG =ConfigObj(DB_CONF_FILE)# DatabasanslutningsparametrarDB_HOST =DB_CONFIG['DB_HOST']DB_NAME =DB_CONFIG['DB_NAME']DB_USER =DB_CONFIG['DB_USER']DB_PASSWORD =DB_CONFIG ='DB_CONFIG='DB_DBASE_PASSFIGWORD'='DB_DBASE_PASSFIGWORD' { 'default':{ 'ENGINE':'django.db.backends.postgresql', 'NAME':DB_NAME, 'USER':DB_USER, 'PASSWORD':DB_PASSWORD, 'HOST':DB_HOST, 'PORT':DB_PORT, } }

Ändra databasens "session" enligt ovan.

Skapa symboliska länkar för manage.py: 

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

För att underlätta vårt arbete skapade vi en symbolisk länk till manage.py i bin-katalogen som finns i vår $PATH.

Kör virtuell webbserver: 

$ manage.py runserver 0.0.0.0:8000

Testa i din webbläsare:http://localhost:8000 och sedan + C för att avbryta.

Åtkomst till projektkatalogen: 

$ cd src

Låt oss kontrollera filerna i den aktuella katalogen: 

$-träd .

Utdata:

.├── manage.py└── my_project ├── db.conf ├── __init__.py ├── __pycache__ │ ├── pyinit │c ├c .pyc │ ├── urls.cpython-38.pyc │ └── wsgi.cpython-38.pyc ├── settings.py ├── urls.py ─>─ 

 Lista innehållet i aktuell katalog i ett trädliknande format.
Här ser vi alla filer i projektet.
 

 
 

 Första migreringen för Django-metadata: 
 
$ manage.py migrera
 

 
 

 Skapande av superanvändare av Django: 
 
$ manage.py createsuperuser
 

 
 

 Skapa en app: 
 
$ manage.py startapp human_resource
 

 
 

 Redigera settings.py för att lägga till ny app: 
 
$ 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', # Custom Apps 'human_resource',]
 

 Ett coolt Django-trick:du kan använda en katalogmodell istället för en fil models.py.
Men du måste skapa en dunder init-fil (__init__.py) inuti models-katalogen.
Låt oss gå!
 

 
 

 Skapande av modellkatalogen i appkatalogen: 
 
$ mkdir human_resource/models
 

 
 

 Ta bort filen models.py: 
 
$ rm -f human_resource/models.py
 

 
 

 Skapa modell: 
 
$ vim human_resource/models/hr.py
 
från django.db.models import AutoFieldfrom django.db.models import Modelfrom django.db.models import TextFieldclass Person(Model):''' Person Model Namespace:ns_hr Tabell:tb_person ''' id_ =AutoField(db_column='id_', name='id', primary_key=True,) name =TextField(db_column='name', name='name',) efternamn =TextField(db_column='efternamn', namn='efternamn',) def __str__(self):return f'{self.name} {self.surname}' class Meta:db_table ='ns_hr"."tb_person' # 'schema"."object' verbose_name_plural ='Person'
 

 För att dra nytta av fördelarna med PostgreSQL-scheman, inuti din modell, i Meta inre class, till värdet av attributet "db_table" måste du sätta en punkt som skiljer namnutrymme och objekt mellan citattecken.
 

 'schema"."object' 
 

 Objektet kan vara en tabell eller en vy, till exempel...
 

 
 

 Dunder init i modellkatalogen för att migreringarna träder i kraft: 
 
vim human_resource/models/__init__.py
 
från human_resource.models.hr import person
 

 Detta är nödvändigt för att modellkatalogen fungerar som en models.py-fil.
 

 
 
(Nej) Migreringar:Min databas, mina regler!
 

 Vi skapar strukturen för vår databas och ingen ORM borde göra det åt oss!
Vi har makten!
Vi har makten!
Vi har kommandot!
 

 Vår databas, våra regler! 😉
 

 Modellera bara din databas med dina egna händer och gör en falsk Django-migrering.
För det är bara vi som vet hur databasobjekten måste skapas 😉
 

 
 

 Gör migrering för human_resource-appen: 
 
$ manage.py makemigrations human_resource
 

 
 

 Falsk migrering: 
 
$ manage.py migrate --fake
 

 
 

 Låt oss kontrollera kataloghierarkin för appen: 
 
$ tree human_resource/
 
human_resource/├── admin.py├── apps.py├── __init__.py├── migrations│ ├── 0001_initial.py└ ├│ca ├│che 0001_initial.cpython-38.pyc│ └── __init__.cpython-38.pyc├── modeller│ ├── hr.py│ ├── └ __init __.py─└ __init __.py .pyc│ └── __init__.cpython-38.pyc├── __pycache__│ ├── admin.cpython-38.pyc│ └─└ __init-__.cpython└ __init-__.cpython└c py
 

 
 

 Django Shell (Ipython): 
 
$ manage.py-skal
 
>>> från human_resource.models.hr import Person>>> p =Person(namn='Ludwig', efternamn='van Beethoven')>>> print(p)
 

 Utdata:
 
Ludwig van Beethoven
 
>>> p.save() # Behåller i databasen
 

 Tryck på <Ctrl> + D att avsluta!
 

 
 

 Databasskal (psql): 
 
$ manage.py dbshell
 

 En fråga för att kontrollera om data infogades av Django:
 
> VÄLJ id_, namn, efternamn FRÅN ns_hr.tb_person;
 

 Utdata:
 
 id | namn | efternamn ----+--------+--------------- 1 | Ludwig | van Beethoven
 

 
 
Slutsats
 

 PostgreSQL är ett robust och kraftfullt RDBMS med många funktioner, inklusive namnutrymmen för dess objekt.
Django är ett fantastiskt webbramverk som är mycket robust och har många funktioner också.
Så du kan extrahera det bästa av båda för att uppnå bättre resultat och för att göra detta är ett av sätten att få en bättre organisation.
Att organisera dina databasobjekt i namnutrymmen enligt dess roller kommer att ge dig fördelar 😉

  1. Hur man ersätter (null) värden med 0 utgång i PIVOT

  2. Vad är vårintegration?

  3. Fönsterfunktioner eller vanliga tabelluttryck:räkna tidigare rader inom intervallet

  4. Praktiskt processorval för SQL Server 2014/2016 OLTP-arbetsbelastningar