Brauche ich einen primary key für meine Tabelle, die einen EINDEUTIGEN (zusammengesetzten 4-Säulen), von denen eine NULL ist?

Sollte ich eine "serielle" primary key falls ich jemals einen brauchen?

Können Sie ganz einfach eine serial-Spalte später, wenn Sie einen brauchen:

ALTER TABLE product_pricebands ADD COLUMN id serial;

Wird die Spalte gefüllt werden mit einzigartigen Werte automatisch. Auch können Sie stellen Sie den primär-Schlüssel in der gleichen Anweisung (wenn kein Primärschlüssel definiert ist, aber dennoch):

ALTER TABLE product_pricebands ADD COLUMN id serial PRIMARY KEY;

Wenn Sie auf die Tabelle aus anderen Tabellen, die ich würde Ihnen raten, einen solchen Surrogat Primärschlüssel, denn es ist ziemlich schwerfällig, um link durch vier Spalten. Es ist auch langsamer in SELECTs mit JOINs.

Entweder Weg, Sie sollte einen Primärschlüssel definieren. Der EINDEUTIGE index, darunter eine null-Spalte ist nicht ein vollständiger Ersatz. Es kann Duplikate für Kombinationen, darunter ein NULL-Wert, da die zwei NULL-Werte sind nie als die gleichen. Dies kann zu Schwierigkeiten führen.

Als

den colourid Feld kann NULL sein,

möglicherweise möchten Sie erstellen zwei eindeutige Indizes. Die Kombination (template_sku, siteid, currencyid, colourid) keine PRIMARY KEY wegen der null-Werte zulässt colourid, aber Sie können erstellen ein UNIQUE Einschränkung, wie Sie bereits haben (die Umsetzung eines index automatisch):

ALTER TABLE product_pricebands ADD CONSTRAINT product_pricebands_uni_idx
UNIQUE (template_sku, siteid, currencyid, colourid)

Dieser index deckt perfekt den Fragen, die Sie erwähnen, in 2).

Erstellen Sie eine teilweise eindeutigen index zusätzlich, wenn Sie wollen vermeiden, "Duplikate" mit (colourid IS NULL):

CREATE UNIQUE INDEX product_pricebands_uni_null_idx
ON product_pricebands (template_sku, siteid, currencyid)
WHERE colourid IS NULL;

Decken alle Basen. Ich schrieb mehr über diese Technik in einem Verwandte Antwort auf dba.SE.

Die einfache alternative zu den oben genannten ist, um colourid NICHT NULL, und erstellen Sie eine primäre Taste anstelle der oben product_pricebands_uni_idx.

Ist auch, wie Sie

grundsätzlich LÖSCHEN die meisten Daten

für Ihre refill-Betrieb, wird es schneller sein, um die drop-Indizes, die sind nicht benötigt während der refill-Vorgang, und erstellen Sie diese anschließend. Es ist schneller, um eine Größenordnung zu bauen, die einen index von Grund auf als für alle Zeilen inkrementell.

Woher wissen Sie, welche Indexe benutzt (gebraucht)?

• Testen Sie Ihre Abfragen mit EXPLAIN ANALYZE.
• Oder verwenden Sie den integrierte Statistiken. pgAdmin zeigt die Statistik in einer separaten Registerkarte für das ausgewählte Objekt.

Kann es auch schneller sein, wählen Sie die wenigen Zeilen mit my_custom_field = TRUE in eine temporäre Tabelle, TRUNCATE der Basis-Tabelle und LEGEN Sie die re-überlebenden. Hängt davon ab, ob Fremdschlüssel definiert. Würde dann so Aussehen:

CREATE TEMP TABLE pr_tmp AS
SELECT * FROM product_pricebands WHERE my_custom_field;

TRUNCATE product_pricebands;
INSERT INTO product_pricebands SELECT * FROM pr_tmp;

Dies vermeidet eine Menge Staubsaugen.