View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000686 | Fakturama | Kontakte (Contacts) | public | 2018-06-01 17:03 | 2019-12-06 21:26 |
Reporter | LastBoyScout | Assigned To | rheydenr | ||
Priority | urgent | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 2.0.1 | ||||
Fixed in Version | 2.1.0 | ||||
Summary | 0000686: Datenbankinkonsistenz - Leere Datensätze und mögl. Datensätze mit verlorenem Bezug | ||||
Description | Aufgrund der momentanen Datenbankstruktur kommt es leider mindestens bei den Kontakten und Adressen zu Inkonsistenzen und Datenbankleichen... Siehe hierzu den Forenbeitrag unter: https://forum.fakturama.info/read.php?2,11778 Nachfolgend daher nochmal mein detaillierter Vorschlag: In der Tabelle fkt_contact sollten wirklich nur die einmaligen Daten enthalten sein und es sollte zu jedem Kreditor / Debitor auch nur einen einzigen Eintrag geben. Die Datenfelder zu denen auch mehrere Einträge existieren können, sollten hingegen in fkt_address bzw. fkt_bankaccount abgelegt werden, wo es dann auch jeweils mehrere bzw. sogar beliebig viele Einträge je Kreditor / Debitor geben kann. Sofern ein Kontakt oder eine bestimmte Adresse nicht gelöscht sondern nur gesperrt werden soll, kann in den Tabellen ein Bitwert BLOCKED auf 1 gesetzt werden. Dieser Kontakt oder auch nur die betreffende Adresse oder Bankverbindung ist dann ausgegraut und nicht verwendbar. Innerhalb von Fakturama sollte die Maske dann wie bereits von Ralf Vorgeschlagen (siehe Anhang, jedoch noch erweitert um Telefonnummern, Mailadresse usw.) umgesetzt werden. Als Anhang (Zusätzliche Informationen) nun nochmal die Umsetzung mit InnoDB als Engine. Hier werden bei einem evtl. Update eines Datensatz die entsprechenden Bezüge in der Hilfstabelle automatisch mit aktualisiert. Wird eine Adresse oder Bankverbindung gelöscht, wird automatisch auch gleich der entsprechende Bezugsdatensatz zum Kontakt entfernt. Und wenn ein Kontakt gelöscht wird, werden neben all seinen Bezügen auch gleich die dazugehörigen Adressen und Bankverbindungen entfernt. So kann es weder zu falschen Beziehungen noch zu Karteileichen kommen. Das ganze erfolgt dann direkt über die DB, Fakturama muss sich nicht darum kümmern. | ||||
Steps To Reproduce | Bislang sind in fkt_address ja eigentlich nur Straße, PLZ, Ort und Land hinterlegt, die dazugehörigen Namen werden aber weiterhin in fkt_contact abgelegt. Dies hat dann natürlich unschöner Weise zur folge das zu jeder Lieferanschrift auch ein weiterer Kontakteintrag angelegt werden muss, nur um Namen und Fremdkey der Adresse zu hinterlegen. Eigentlich soll doch aber nur eine abweichende Lieferanschrift gespeichert werden und nicht auch noch ein alternativer Kontakt bei dem zu allem Übel auch noch alle übrigen Felder leer oder ungenutzt (z.B. Telefonnummern usw.) bleiben. Entfernt man in Fakturama bei einem Kontakt das Häkchen bei "Abweichende Lieferanschrift", geht nur der Bezug FK_ALTERNATECONTACT verloren und in der DB bleiben gleich zwei Karteileichen zurück (zumindest in mySQL). Bei den Bankdaten wird ebenfalls zu jedem Kontakt ein Datenbankeintrag erstellt, auch wenn in den Feldern keine Daten eingetragen werden. Daher kommt es auch hier zu Leeren Datensätzen. | ||||
Additional Information |
| ||||
Tags | database | ||||
Attached Files | |||||
|
Der Vorschlag wird als Umsetzungshilfe aufgegriffen. Die Variante mit dem Bitmuster wird allerdings nicht umgesetzt, da der Datenbank-Zugriff über eine ORM-Schicht erfolgt. Da würde das zu erheblichen Komplikationen führen. Die Verknüpfungstabellen werden automatisch erstellt (auch durch den ORM-Mapper). Wichtig wäre hier vor allem eine Migrationsstrategie der bereits erfaßten Daten. Das wird nochmal analysiert. |
|
Sofern ein Bitmuster von ORM nicht umgesetzt werden kann, muss in den Verknüpfungstabellen eben für jede Beziehungsart (Beleggruppen und Kontoarten) eine eigene Spalte bit(1) hinterlegt werden. Da die Primären- Kontaktdaten einen Wert in CUSTOMERNUMBER haben wo bei den Sekundären immer NULL ist, kann man die zusammengehörige Daten ja per JOIN verknüpfen: Diese Datensätze kann man dann in einer Temporären Tabelle zwischenspeichern um es nach dem Umbau in die neue Tabellenstruktur zu überführen. Auch wenn MyISAM als Standard angegeben ist, kann man beim erstellen einer Tabelle doch trotzdem InnoDB als Engine auswählen! |
|
Mit einem OR-Mapper ist das leider etwas komplizierter, weil man da nicht direkt auf die jeweilige Datenbank geht. Ich mach mir dazu noch ein paar Gedanken. |
|
Dachte so ein OR-Mapper soll einen die Arbeit erleichtern? ;-) Bez. dem Löschen, insbesondere von personenbezogenen Daten, sollte man nochmal in Klausur gehen: P.S. Musste neulich Adressen verifizieren und da wird ein String aus Straße inkl. Hausnummer oftmals zum Knackpunkt. Wenn man bei den Adressdaten daher einmal einen Umbau vornimmt, schlage ich vor dabei auch die Hausnummer in einen extra Spalte zu überführen. |
|
Mir hat bislang eigentlich das DELETED-Flag ausgereicht. Das sorgt ja dafür, daß der Datensatz nirgends mehr auftaucht. Wenn man aber eine Rechnung hat, die diesen Satz referenziert, sollte das ja nicht in einem Fehler enden. |
|
Mit der richtigen Strategie muss es ja nicht zwangsläufig in einem Fehler enden. Bei einem entsprechenden Löschantrag gem. DSGVO sind ja nur die Daten mit unmittelbarem Personenbezogenen zu Löschen, sofern keine anderweitige Vorschrift dem entgegensteht (z.B. gesetzl. Archivierugsfrist noch nicht abgelaufen). Alle Übrigen Daten z.B. PLZ, Ort usw. können natürlich weiterhin erhalten bleiben. Die betroffenen Daten müssen dann aber auch wirklich gelöscht werden. Ein DELETED-Flag über welches die Daten nur ausgeblendet werden, ist eben nicht zulässig. |
|
Wurde mit 0000624 behoben. Die alten Daten wurde vorsichtshalber in eine andere Tabelle verschoben, um notfalls noch Zugriff darauf zu haben. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-06-01 17:03 | LastBoyScout | New Issue | |
2018-06-01 17:03 | LastBoyScout | Tag Attached: database | |
2018-06-01 17:03 | LastBoyScout | File Added: contacteditor_address.png | |
2018-06-01 23:52 | rheydenr | Additional Information Updated | |
2018-06-01 23:52 | rheydenr | Assigned To | => rheydenr |
2018-06-01 23:52 | rheydenr | Status | new => assigned |
2018-06-25 00:01 | rheydenr | Note Added: 0000772 | |
2018-06-25 00:05 | rheydenr | Note Edited: 0000772 | |
2018-06-25 12:06 | LastBoyScout | Note Added: 0000774 | |
2018-06-25 20:41 | rheydenr | Note Added: 0000777 | |
2018-06-29 11:59 | LastBoyScout | Note Added: 0000782 | |
2018-06-30 01:18 | rheydenr | Note Added: 0000787 | |
2019-02-08 10:39 | LastBoyScout | Note Added: 0000868 | |
2019-02-18 20:52 | rheydenr | Relationship added | related to 0000624 |
2019-12-06 21:26 | rheydenr | Status | assigned => closed |
2019-12-06 21:26 | rheydenr | Resolution | open => fixed |
2019-12-06 21:26 | rheydenr | Fixed in Version | => 2.1.0 |
2019-12-06 21:26 | rheydenr | Note Added: 0000947 |