Ich plane eine Datenbank, um viel Text zu speichern. (Blog-Posts, Nachrichtenartikel usw.) Die Datenbank muss die Felder Titel, Inhalt (max. 50.000 Zeichen), Datum, Link und Sprache enthalten. Der gleiche Inhalt kann nicht auf einem Link vorkommen. Alte Inhalte (zum Beispiel älter als 30 Tage) werden gelöscht.

Das Problem ist jetzt der Primärschlüssel. Ich könnte einfach ein automatisch inkrementierendes Feld (SERIAL-Typ) festlegen und es als Primärschlüssel verwenden. Aber es scheint dumm und eine Verschwendung von Speicherplatz, weil das Feld keinen anderen Zweck erfüllt, als ein Primärschlüssel zu sein. (Und das Feld könnte irgendwann ausgehen oder nicht?) Und es gibt immer noch ein anderes Leistungsproblem: Der Inhalt jeder neu eingefügten Zeile muss auf Duplikate überprüft werden. Die andere Lösung für den Primärschlüssel, die ich mir ausgedacht habe, wäre, einen sha256-Hash von Inhalt + Linkwert zu berechnen und diesen dann in eine neue 'Hash'-Spalte zu setzen und diesen als Primärschlüssel zu verwenden. Zwei Fliegen mit einer Klappe. Das Problem dabei sind natürlich Hash-Kollisionen. Ist es eine große Bedrohung?

Ich habe keine Erfahrung mit PostgreSQL und sehr wenig Erfahrung mit DBMS im Allgemeinen. Daher würde ich mich über eine zweite Meinung freuen, bevor ich eine Datenbank mit den Leistungsmerkmalen einer Schnecke auf der Autobahn erstelle (schrecklicher Vergleich).

Bitte helfen Sie mir hier, wenn Sie Erfahrung mit großen Datenbanken haben. Ist das Festlegen einer 64-stelligen Zeichenfolge als Primärschlüsselfeld in meiner Situation eine gute Idee? (weil ich den Eindruck habe, dass dies generell vermieden wird)