nicht angemeldet
yo,
ich habe ein weing gebraucht, um zu verstehen, was genau du meinst. ich hoffe doch, dass jetzt der groschen bei mir gefallen ist.
ich kenne mich in postgres nicht aus, aber ein primary key besteht grundsätzlich aus zwei constrainst, nämlich UNIQUE und NOT NULL. wenn nun eine spalte(n) schon einen constraint primary key zugewiesen ist, dann braucht man das NOT NULL und das UNIQUE nicht noch einmal expliziet hizufügen.
Da ich aber die Serials (x_no und y_no) eigentlich sowieso nicht brauche (außer zum linken) und die entries unique not null sind, ist meine Frage, ob ich gleich die entries als Primärschlüssel deklarieren kann und den Index auf diesen Aufbauen.
wie Rouven schon sagte, einen künstlichen schlüssel als pk zu nehmen, macht durchaus sinn. aber das ist ansichtssache und muss jeder dba selber entscheiden.
den namen der spalte serial würde ich ändern, da es meiner meinung nach bessere namen gibt, wie zum beispiel id. dann wird es deutlicher, dass es sich um einen künstlichen schlüssel handelt. nur zum verlinken brauchst du diese spalte nicht, da du eine weitere spalte hast, die ebenfalls NOT NULL und UNIQUE ist. aber dann kommt wieder die frage nach dem künstlichen schlüssel oder nicht. wenn er nun schon mal da ist, würde ich ihn auch bestehen lassen.
wie bereits erwähnt, legt das dbms für jeden primary key auch einen index an. auch diesen schritt kannst du dir sparen. tuning an sich ist ein schwieriges thema. man kann solche aussagen wie die frage nach einem index nicht so allgemein beantworten, dass das tuning von vielen dingen abhängt. das vorhandensein eines index kann die abfrage sogar langsamer machen.
mit anderen worten, ob deine abfragen schneller werden hängt von dem speziellen fall ab.
Ilja