Differences between revisions 4 and 8 (spanning 4 versions)
Revision 4 as of 2009-03-10 12:42:25
Size: 1269
Editor: dial-92-52-21-192-orange
Comment:
Revision 8 as of 2009-03-10 13:02:10
Size: 2110
Editor: dial-92-52-21-192-orange
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
Ideme implementovať dátový model žiackej knižky naivným (a nesprávnym) spôsobom: Ideme implementovať dátový model žiackej knižky naivným (a pre tento účel nesprávnym) spôsobom:
Line 22: Line 22:

V adresári ziacka máme súbor {{{models.py}}}, ktorý vyzerá takto:

{{attachment:models.py}}

Napíšme teraz
{{{
$ ./manage.py syncdb
}}}
a všimnime si, že vo výpise máme takýto riadok
{{{
Creating table ziacka_znamka
}}}
Pre zaujímavosť sa môžeme pozrieť, aké SQL príkazy boli použité na vytvorenie tabuľky.
{{{
$ ./manage.py sqlall ziacka
BEGIN;
CREATE TABLE "ziacka_znamka" (
    "id" integer NOT NULL PRIMARY KEY,
    "meno_ziaka" varchar(30) NOT NULL,
    "priezvisko_ziaka" varchar(30) NOT NULL,
    "meno_ucitela" varchar(30) NOT NULL,
    "priezvisko_ucitela" varchar(30) NOT NULL,
    "predmet" varchar(50) NOT NULL,
    "znamka" integer unsigned NOT NULL
)
;
COMMIT;
}}}

Všimnite si, že vzniklo niečo, čo sme explicitne nepožadovali a to stĺpec {{{id}}}.

Jednoduchý model a práca s ním

Django umožňuje pracovať s relačnou databázou pomocou objektovo-relačného modelu. Robí to pomocou techniky menom objektovo-relačné mapovanie (ORM). Z praktického hľadiska táto technika slúži na izolovanie programátora aplikácie od databázového servra, Je možné začať vyvíjať aplikáciu lokálne pod sqlite a v reálnom nasadení potom použiť povedzme Oracle, pričom jediná zmena je v settings.py. Programátor sa nemusí zaoberať SQL, stačí mu vedieť python.

Nevýhoda tejto techniky je v tom, že neumožňuje účinne používať mnohé techniky určené pre zvýšenie výkonnosti databázového servra (triggery a pod.). Primárnym účelom djanga je vytvárať dynamické webové stránky, ale napríklad veľká aplikácia ako napríklad http://is.stuba.sk vyžaduje trochu zložitejší návrh databázovej schémy, než to umožňuje django.

Začnime

Vytvorme si nový projekt s názvom skola a v ňom aplikáciu s názvom ziacka.

Ideme implementovať dátový model žiackej knižky naivným (a pre tento účel nesprávnym) spôsobom: ako jednu veľkú tabuľku s mnohými stĺpcami. Nesmieme zabudnúť doplniť aplikáciu v settings.py.

V adresári ziacka máme súbor models.py, ktorý vyzerá takto:

   1 from django.db import models
   2 
   3 class Znamka(models.Model):
   4 
   5     # meno a priezvisko ziaka
   6     meno_ziaka=models.CharField(max_length=30)
   7     priezvisko_ziaka=models.CharField(max_length=30)
   8     # meno a priezvisko ucitela
   9     meno_ucitela=models.CharField(max_length=30)
  10     priezvisko_ucitela=models.CharField(max_length=30)
  11     # predmet, z ktoreho bola znamka udelena
  12     predmet=models.CharField(max_length=50)
  13     # znamka
  14     znamka=models.PositiveIntegerField()

models.py

Napíšme teraz

$ ./manage.py syncdb

a všimnime si, že vo výpise máme takýto riadok

Creating table ziacka_znamka

Pre zaujímavosť sa môžeme pozrieť, aké SQL príkazy boli použité na vytvorenie tabuľky.

$ ./manage.py sqlall ziacka
BEGIN;
CREATE TABLE "ziacka_znamka" (
    "id" integer NOT NULL PRIMARY KEY,
    "meno_ziaka" varchar(30) NOT NULL,
    "priezvisko_ziaka" varchar(30) NOT NULL,
    "meno_ucitela" varchar(30) NOT NULL,
    "priezvisko_ucitela" varchar(30) NOT NULL,
    "predmet" varchar(50) NOT NULL,
    "znamka" integer unsigned NOT NULL
)
;
COMMIT;

Všimnite si, že vzniklo niečo, čo sme explicitne nepožadovali a to stĺpec id.

KMaDGWiki: ProgramovanieInternetovychAplikacii/SimpleModel (last edited 2009-03-10 20:54:20 by dial-92-52-21-192-orange)