![]() |
Datenbank: interbase • Version: egal • Zugriff über: egal
Tabellenaufbau
Guten Tag,
ich möchte für meine kleine, spezielle Vereinssoftware eine Zugriffshistory anlegen. Dies wird nach der Datenschutzgrundverordnung verlangt. In dieser History soll abgelegt werden: Wer hat sich wann am Programm angemeldet und was hat er in welchem Programmteil getan. Auch soll eine Auswertung in Form eines Druckes enthalten sein, a) über alle Aktivitäten und auch b) speziell für einen Programmnutzer. Dazu dachte ich mir, das ich 3 Tabellen benötigen werden. Da sehr wahrscheinlich sehr viele Zugriffe über das Jahr verteilt stattfinden werden, möchte ich keine Generatoren als PrimaryKey verwenden, sondern den Hauptschlüssel der Tabellen über 2 Spalten erzeugen. So wie ich es im Codebeispiel zeige, kann es nicht funktionieren. Ich muss ja die Tabellen mit einander über die Hauptschlüssel verbinden und dies ist in meinem Beispiel sehr unglücklich gelöst. Deshalb meine Fragen: a) Wie würdert Ihr es lösen? b) Wie würdet Ihr den Hauptschlüssel aufbauen? 1. Tabelle Anmeldung 2. Tabelle Protokolle 3. Tabelle Abmeldung
Delphi-Quellcode:
Vielen Dank für Eure fachmännischen Hilfen im Voraus.
dtmdMain.bpsql.Close;
dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('create table ProtAnmeldung ( ' + 'angemeldetam timestamp not null, ' + 'adressid integer not null, ' + 'brdname do62 )'); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; dtmdMain.bpsql.Close; dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('alter table protanmeldung add primary key (angemeldetam, adressid) '); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; dtmdMain.bpsql.Close; dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('create table protokolle ( ' + 'loprotokolleid timestamp not null, ' + 'adressid integer not null, ' + 'menuename do50, ' + 'protokoll blob )'); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; dtmdMain.bpsql.Close; dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('alter table protokolle add primary key (loprotokolleid, adressid) '); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; dtmdMain.bpsql.Close; dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('create table protabmeldung ( ' + 'abgemeldetam timestamp not null, ' + 'adressid integer not null )'); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; dtmdMain.bpsql.Close; dtmdMain.bpsql.SQL.Clear; dtmdMain.bpsql.SQL.Add('alter table protabmeldung add primary key (abgemeldetam, adressid) '); dtmdMain.bpsql.Prepare; dtmdMain.bpsql.ExecQuery; |
AW: Tabellenaufbau
Hallo,
Zitat:
Zitat:
Zitat:
![]() Generators return a 64-bit value 64bit -> 2^64 -> rechne mal aus, wie viele Mio. Jahre sich tausende Anwender (ja, ich übertreibe ;) ) sich da an- und abmelden können. Nimm Int64 oder eine GUID als PK, aber keine Doppelfelder. Und vor allem, nimm künstliche Schlüssel als PK, die mit dem eigentlichen Dateninhalt nichts zu tun haben. |
AW: Tabellenaufbau
Aus der holen Hand
Table_Connection:
Table_Action:
Damit solltest Du die wesentlichen Anforderungen abdecken können. Gruß K-H P.S. Über den Einsatz von Generatoren sollte man nicht nachdenken. Wenn es eng werden könnte, dann nimmt man für die Log-Tabellen eben eigene Generatoren |
AW: Tabellenaufbau
Hallo,
Zitat:
Pro Tabelle wird ein Generator benutzt. |
AW: Tabellenaufbau
Dass die DSGVO eine Zugriffshistory verlangt, würde mich wundern. Meines Wissens sind technisch/organisatorische Maßnahmen zu ergreifen, dass nur Befugte auf die Daten zugreifen können. Aber vielleicht ist das bei Euch in D wirklich so anders als bei uns in A.
Ich würde eine einzige Tabelle nehmen, PK ist eine generierte ID, dann gibt es noch eine Referenz auf die Person + was(!) sie wann(!) (+ev. womit) gemacht hat. Dann kannst du alles ermitteln, was du brauchst: - wer hat sich in einem Zeitraum angemeldet? - Wer hat X gemacht? In die Tabelle kannst du sogar Teile des Datenbestands kopieren, wenn du genau nachvollziehen willst, was gemacht wurde. |
AW: Tabellenaufbau
Den Bedarf seh ich auch nicht so recht gemäß DSGVO.
Solange es reguläre Zugriffe durch Vereinsmitglieder mit entsprechenden Aufgabenbereichen sind, gehört es eher in die Datenschutzerklärung rein. Es wird halt mit den Daten gearbeitet, entsprechend des Bedarfs. @generatoren Man nimmt meist einen pro Spalte/Tabelle, aber das kann man auch anders machen und dafür gibt es einen Grund. Das ist "Widerstandskraft" gegen Fehlbedienung (durch Admin, Entwickler, ..) |
AW: Tabellenaufbau
Änderungen sollte man protokollieren. Aber die Protokollierung von Zugriffen wäre ja eher ein Verstoss gegen den Datenschutz.
|
AW: Tabellenaufbau
Zitat:
@MKinzler Ist in einem Betrieb problematisch wg. Leistungsüberwachung. Gruß K-H |
AW: Tabellenaufbau
Zitat:
Die DSGVO enthält keine technischen Vorgaben oder Einschränkungen. Im Grundsatz verlangt sie Transparenz und Nachvollziehbarkeit, was mit den Daten geschieht unter dem Gesichtspunkt "nur was notwendig ist" und "nicht länger als notwendig". Das "notwendig" ist zu begründen und zu dokumentieren. |
AW: Tabellenaufbau
zusätzlich muß die Person deren Daten erfaßt werden, darüber informiert werden, daß die Daten erfasst werden.
Gruß K-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz