django model optimieren / primary key ändern?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich hab in PyLucid v0.9 eine IP ban liste erstellt und frage mich gerade ob das model nicht ein wenig optimiert werden sollte. Gerade sieht es so aus (gekürzt):

Code: Alles auswählen

class BanEntry(models.Model):
    createtime = models.DateTimeField(default=datetime.datetime.utcnow)
    ip_address = models.IPAddressField()
Auf Geschwindigkeit sollte die Tabelle darauf optimiert sein, heraus zu finden ob die aktuelle IP existiert oder nicht.

Ich denke in jedem Fall macht es wohl Sinn beim "ip_address" Feld ein db_index=True und unique=True einzufügen.

Aber wäre es vielleicht noch besser/schneller die ip_address als primary_key zu nutzten?

Was meint Ihr?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Im Zweifel messen. Das ist besser als Raten. Aber ich rate, dass es bei einer DB egal ist, ob es ein Index wegen primary key oder ein anderer eindeutiger Index ist.

Wenn du den PK nicht als FK in anderen Modellen brauchst, würde ich wohl den üblichen Integerwert einsparen und direkt die IP benutzen.

Stefan
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

sma hat geschrieben:Wenn du den PK nicht als FK in anderen Modellen brauchst, würde ich wohl den üblichen Integerwert einsparen und direkt die IP benutzen.
Ne, FK habe ich nicht. Ich probiere das mal ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Zumindest in Postgresql ist ein PK auch nix anderes als eine Kombi aus Not null und unique constraint, deshalb bringt ein PK aus der IP auch keinen Geschwindigkeitsvorteil. Das wird bei Mysql auch nicht anders sein ...
Antworten