Jak rozmieścić constrainty w tabeli?

Dziękuję za odpowiedzi na mój poprzedni wątek. Przemyślałem problem i postanowiłem go uprościć:

W miasteczku Warzywniak Dolny jest hurtownia warzyw. Wśród wielu warzyw, które ma ona w swoich magazynach, jest cebula. Dane dostawców hurtownia gromadzi w bazie postgresql.

Jedną z tabel zawierających taką informację jest tabela "Dostawcy" z kolumnami:

• row_id - numer wiersza
• vege_id - numer porządkowy wiersza datasetu
• natmkt_vgtbl - id warzywa w systemie krajowym
• cmpn_vgtbl - id warzywa w systemie firmy
• euroveget_vgtbl - id warzywa w systemie EU
• vege_cmpny_id - id dostawcy z faktury
• vege_cmpny_name - nazwa dostawcy z faktury

Przykładowy wpis do bazy pokazuję w wierszu 2 załącznika. Przy nazwach kolumn podaję nazwy constraintów. Pewnego dnia dostawca zmienił nazwę, z zachowaniem poprzednich id we wszystkich systemach. Jak pokazać ten fakt w bazie, nadpisując istniejący wiersz przy pomocy INSERT INTO?

No to żeś opisał ...

Z tego opisu niewiele wynika natomiast wnioskuję, że vege_cmpny_id jest nowe tak samo jak vege_cmpny_name zatem nowe produkty powinny wpadać z nowym ID. Jak chcesz stare zaktualizować do nowego słownika to musisz wyszukać te z vege_cmpny_id = 'zdrocbl' i zrobić update na nowe wartości ... z czym masz tak naprawdę problem?

Bazodanowiec6 napisał(a):

Pewnego dnia dostawca zmienił nazwę, z zachowaniem poprzednich id we wszystkich systemach. Jak pokazać ten fakt w bazie, nadpisując istniejący wiersz przy pomocy INSERT INTO?

Przy pomocy INSERT INTO pewnie się nie da, bo to dodałoby nowy wpis z nowym id, i pewnie musiałbyś usunąć stare.

Na moje, to skoro masz zarówno id jak i nazwę dostawcy (vege_cmpny_id i vege_cmpny_name), to możesz po prostu zaktualizować vege_cmpny_name używając UPDATE.

PS: Wręcz ta kolumna vege_cmpny_name jest niepotrzebna - po co Ci ona skoro masz vege_cmpny_id?

Nie da się mieć 2 rekordów o tej samej wartości PK w jednej tabeli. Czyli przy użyciu INSERT się nie da.
Typowo, w relacyjnej bazie danych przechowujesz stan aktualny rzeczywistości. Dodanie do tego historii zwykle bywa nieco złożone i nie ma jednego uniwersalnego sposobu na implementację.

PS: Wręcz ta kolumna vege_cmpny_name jest niepotrzebna - po co Ci ona skoro masz vege_cmpny_id?

Przy sytemach w których wystawia sie faktury trzymanie nazwy i adresu na fakturze i id ma jak najbardziej sens. Zmiana nazwy firmy czy adresu to nie jest nic wyjątkowego.
W ten sposób mozna właśnie tworzyć historycznośc wpisów, bo na fakturze mają być dane na dzień wystawienia, a w kartotece aktualne.
Wiem można tworzyć tabęlę ze zmianami w nazwie adresie od danej daty, kwestia decyzji. Ja jestem zwolennikiem trzymania tego bezpośrednio na fakturze.