Datenbankentwurf. Und bekommen Zeitpunkt der letzten Änderung mit jeder Spalte in PostgreSQL

Question

Meine Datenbank/table jeder Endpunkt/Umfang mehrere Tabellen haben,
zB Benutzer: Benutzer, user_information, user_role ...
Ich frage mich, sollte ich Tabelle trennen wie unten, oder nicht?

Dies ist mein erstes Mal, ein Produkt zu bauen, das nicht wie vorher nur eine einmalige Arbeit kleine Website machen. und das könnte weitere Funktionen in der zukünftigen Version hinzufügen.

Ich bin mir nicht sicher über dieses Überdesign? Hilft separate Tabelle wie diese in Zukunft?
und Nachteile, die ich kenne, ist mehr Tabellenbeitritt verwenden, und schwieriger für mich, um die Abfrage zu erstellen.

jeder Vorschlag, teilen Erfahrung wird wirklich zu schätzen wissen.

Für jetzt kann ich nur vorstellen, ich möchte jede Spalte zuletzt geändert Zeit wissen?

Also, wenn ich jede Spalte zuletzt geänderte Zeit wissen möchte, gibt es irgendeine ursprüngliche Build-Methode in PostgreSQL? oder ich habe für jede Spalte wie email_last_modified_date, username_last_modified_date ...

Endpunkt/scope Benutzer

CREATE TABLE IF NOT EXISTS "user"(
    "id" SERIAL NOT NULL, 
    "create_date" timestamp without time zone NOT NULL, 
    "last_modified_date" timestamp without time zone, 
    "last_modified_by_user_id" integer, 
    "status" integer NOT NULL, 
    PRIMARY KEY ("id") 
); 

CREATE TABLE IF NOT EXISTS "user_information"(
    "id" SERIAL NOT NULL, 
    "create_date" timestamp without time zone NOT NULL, 
    "last_modified_date" timestamp without time zone, 
    "last_modified_by_user_id" integer, 
    "user_id" integer NOT NULL, 
    "email" varchar(100) NOT NULL, 
    "username" varchar(50), 
    "password" varchar NOT NULL, 
    "first_name" varchar(50), 
    "last_name" varchar(50), 
    "website" varchar, 
    "description" varchar, 
    "birth_date" timestamp without time zone, 
    "country" varchar(50), 
    "gender" integer, 
    "file_type" integer, 
    "file_name" varchar(50), 
    "file_extension" varchar(50), 
    "file_portrait" boolean, 
    PRIMARY KEY ("id"), 
    FOREIGN KEY ("user_id") REFERENCES "user" ("id") ON DELETE CASCADE ON UPDATE CASCADE 
); 
CREATE TABLE IF NOT EXISTS "user_role"(
    "id" SERIAL NOT NULL, 
    "create_date" timestamp without time zone NOT NULL, 
    "last_modified_date" timestamp without time zone, 
    "last_modified_by_user_id" integer, 
    "user_id" integer NOT NULL, 
    "role" integer NOT NULL, 
    PRIMARY KEY ("id"), 
    FOREIGN KEY ("user_id") REFERENCES "user" ("id") ON DELETE CASCADE ON UPDATE CASCADE 
); 

merge Tabelle hinzufügen?

CREATE TABLE IF NOT EXISTS "user"(
    "id" SERIAL NOT NULL, 
    "create_date" timestamp without time zone NOT NULL, 
    "last_modified_date" timestamp without time zone, 
    "last_modified_by_user_id" integer, 
    "status" integer NOT NULL, 

    "information_last_modified_date" timestamp without time zone, 
    "information_last_modified_by_user_id" integer, 
    .... user_information 

    "role_last_modified_date" timestamp without time zone, 
    "role_last_modified_by_user_id" integer, 
    ... user_role 
    PRIMARY KEY ("id") 
); 

Answer 1

einen Tisch Stellen für jede Entität (in denen ein Unternehmen etwas Bedeutendes für das Unternehmen ist, die eindeutig identifiziert werden muss) und für jede many-to-many-Beziehung. So erhalten Benutzer, Rolle, Userrole jeweils eine Tabelle. Es gibt keinen Wert, der eine Trennung zwischen Benutzer- und Benutzerinformationen ermöglicht, Sie führen nur einen weiteren Join ein.

Wenn Sie glauben, dass Sie Joins von Benutzer zu Rolle optimal verwalten möchten, ohne die Benutzerinformationen zu laden: Wenn Sie Indizes auf Ihre Tabellen setzen, können viele Abfragen möglicherweise nur den Index verwenden und müssen nicht gelesen werden die Tabelle, sofern nicht bestimmte Daten erforderlich sind. Keine Notwendigkeit, eine separate Benutzerinformationstabelle zu erstellen.

Was Sie mit dem zusammengeführten Beispiel tun, ist mir nicht klar, es scheint ein extremer Fall von Denormalisierung.

Wenn Sie Änderungen verfolgen möchten, können Sie nach event-sourcing suchen, was eine Möglichkeit bietet, eine vollständige Historie der Änderungen zu speichern. Eine Einführung finden Sie unter http://martinfowler.com/eaaDev/EventSourcing.html. Abgesehen davon könnten Sie die Historie für bestimmte Entitäten aufbewahren, für die Sie Änderungen verfolgen möchten. .