Zwei Tabellen, aber nur eine hat Pflichtfelder

[exzel]

Hallo zusammen,

in einem Eingabeformular wird ein Kunde und dessen Arbeitgeber erfasst. Der Kunde wird in einer Tabelle, der Arbeitgeber in einer zweiten Tabelle, welche mit der ersten verknüpft ist, erfasst.

Die Pflichtfelder sind aber beim Kunden nicht beim Arbeitgeber. Angenommen es werden nur beim Kunden Pflichtfelder ausgefüllt. Beim Arbeitgeber wird keine Eintragung vorgenommen. Ist es dann in Ordnung in der Datebanktabelle Arbeitgeber den Primär- und Fremdschlüssel zu setzen auch wenn die restliche Felder wie Name des Arbeitgebers, Straße etc. leer bleiben?

Gruß und Dank!

 

[akretschmer]

Hallo zusammen,

in einem Eingabeformular wird ein Kunde und dessen Arbeitgeber erfasst. Der Kunde wird in einer Tabelle, der Arbeitgeber in einer zweiten Tabelle, welche mit der ersten verknüpft ist, erfasst.

wie erfolgt die Verknüpfung?

Die Pflichtfelder sind aber beim Kunden nicht beim Arbeitgeber. Angenommen es werden nur beim Kunden Pflichtfelder ausgefüllt. Beim Arbeitgeber wird keine Eintragung vorgenommen. Ist es dann in Ordnung in der Datebanktabelle Arbeitgeber den Primär- und Fremdschlüssel zu setzen auch wenn die restliche Felder wie Name des Arbeitgebers, Straße etc. leer bleiben?

Gruß und Dank!

Erklär das bitte anhand von CREATE TABLE - Statements.

 

[ukulele]

in einem Eingabeformular wird ein Kunde und dessen Arbeitgeber erfasst. Der Kunde wird in einer Tabelle, der Arbeitgeber in einer zweiten Tabelle, welche mit der ersten verknüpft ist, erfasst.

So wie ich das verstehe kann ein Kunde dem Formular nach nur einen Arbeitgeber haben und umgekehrt. Wenn das Eingabeformular jedesmal für beide einen Eintrag anlegt macht eine Aufteilung in 2 Tabellen keinen Sinn.

Angenommen es werden nur beim Kunden Pflichtfelder ausgefüllt. Beim Arbeitgeber wird keine Eintragung vorgenommen. Ist es dann in Ordnung in der Datebanktabelle Arbeitgeber den Primär- und Fremdschlüssel zu setzen auch wenn die restliche Felder wie Name des Arbeitgebers, Straße etc. leer bleiben?

Nein. Einen leeren Datensatz einzutragen und mit irgendwas zu verknüpfen macht keinen Sinn. Er müsste dann mindestens die Information vermitteln das ein Arbeitgeber existiert, aber unbekannt ist.

 

[exzel]

Hallo und danke für die Meldung! Also die Kunden werden anhand des Schlüssels id_vn Identifiziert und dieser wird dann in der Tabelle Arbeitgeber hinterlegt.

CREATE TABLE IF NOT EXISTS `persdaten` (
  `id_vn` int(11) unsigned NOT NULL auto_increment,
  `id_betreuer` char(25) collate latin1_german2_ci NOT NULL,
  `anrede` varchar(5) collate latin1_german2_ci NOT NULL,
  `name` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorname` varchar(30) collate latin1_german2_ci NOT NULL,
  `gebdatum` date default NULL,
  `familienstand` varchar(15) collate latin1_german2_ci NOT NULL,
  `beruf` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorwahlprivat` varchar(20) collate latin1_german2_ci NOT NULL,
  `telprivat` varchar(20) collate latin1_german2_ci NOT NULL,
  `vorwahlmobil` varchar(20) collate latin1_german2_ci NOT NULL,
  `telmobil` varchar(20) collate latin1_german2_ci NOT NULL,
  `email` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorwahlgesch` varchar(11) collate latin1_german2_ci NOT NULL,
  `telgesch` varchar(20) collate latin1_german2_ci NOT NULL,
  `arbeitgeber` varchar(30) collate latin1_german2_ci NOT NULL,
  `sozialversnr` varchar(40) collate latin1_german2_ci NOT NULL,
  `berufsstatus` varchar(30) collate latin1_german2_ci NOT NULL,
  `kinder` varchar(4) collate latin1_german2_ci NOT NULL,
  `anzahlsteuerkinder` varchar(3) collate latin1_german2_ci NOT NULL,
  `gruppe` char(5) collate latin1_german2_ci NOT NULL,
  `titel` varchar(10) collate latin1_german2_ci NOT NULL,
  `strasse` varchar(20) collate latin1_german2_ci NOT NULL,
  `plz` varchar(5) collate latin1_german2_ci NOT NULL,
  `ort` varchar(15) collate latin1_german2_ci NOT NULL,
  `aktiv` int(11) NOT NULL,
  PRIMARY KEY  (`id_vn`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=218 ;

CREATE TABLE IF NOT EXISTS `arbeitgeber` (
  `id_ag` int(11) NOT NULL auto_increment,
  `id_vn` int(11) NOT NULL,
  `gruppe` char(5) collate latin1_german2_ci NOT NULL,
  `agname` varchar(20) collate latin1_german2_ci NOT NULL,
  `agstrasse` varchar(30) collate latin1_german2_ci NOT NULL,
  `agplz` varchar(5) collate latin1_german2_ci NOT NULL,
  `agort` varchar(20) collate latin1_german2_ci NOT NULL,
  `agtel` varchar(20) collate latin1_german2_ci NOT NULL,
  PRIMARY KEY  (`id_ag`),
  UNIQUE KEY `id_vn` (`id_vn`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=207 ;

Gruß

 

[akretschmer]

Hallo und danke für die Meldung! Also die Kunden werden anhand des Schlüssels id_vn Identifiziert und dieser wird dann in der Tabelle Arbeitgeber hinterlegt.

CREATE TABLE IF NOT EXISTS `persdaten` (
  `id_vn` int(11) unsigned NOT NULL auto_increment,
  `id_betreuer` char(25) collate latin1_german2_ci NOT NULL,
  `anrede` varchar(5) collate latin1_german2_ci NOT NULL,
  `name` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorname` varchar(30) collate latin1_german2_ci NOT NULL,
  `gebdatum` date default NULL,
  `familienstand` varchar(15) collate latin1_german2_ci NOT NULL,
  `beruf` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorwahlprivat` varchar(20) collate latin1_german2_ci NOT NULL,
  `telprivat` varchar(20) collate latin1_german2_ci NOT NULL,
  `vorwahlmobil` varchar(20) collate latin1_german2_ci NOT NULL,
  `telmobil` varchar(20) collate latin1_german2_ci NOT NULL,
  `email` varchar(30) collate latin1_german2_ci NOT NULL,
  `vorwahlgesch` varchar(11) collate latin1_german2_ci NOT NULL,
  `telgesch` varchar(20) collate latin1_german2_ci NOT NULL,
  `arbeitgeber` varchar(30) collate latin1_german2_ci NOT NULL,
  `sozialversnr` varchar(40) collate latin1_german2_ci NOT NULL,
  `berufsstatus` varchar(30) collate latin1_german2_ci NOT NULL,
  `kinder` varchar(4) collate latin1_german2_ci NOT NULL,
  `anzahlsteuerkinder` varchar(3) collate latin1_german2_ci NOT NULL,
  `gruppe` char(5) collate latin1_german2_ci NOT NULL,
  `titel` varchar(10) collate latin1_german2_ci NOT NULL,
  `strasse` varchar(20) collate latin1_german2_ci NOT NULL,
  `plz` varchar(5) collate latin1_german2_ci NOT NULL,
  `ort` varchar(15) collate latin1_german2_ci NOT NULL,
  `aktiv` int(11) NOT NULL,
  PRIMARY KEY  (`id_vn`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=218 ;

CREATE TABLE IF NOT EXISTS `arbeitgeber` (
  `id_ag` int(11) NOT NULL auto_increment,
  `id_vn` int(11) NOT NULL,
  `gruppe` char(5) collate latin1_german2_ci NOT NULL,
  `agname` varchar(20) collate latin1_german2_ci NOT NULL,
  `agstrasse` varchar(30) collate latin1_german2_ci NOT NULL,
  `agplz` varchar(5) collate latin1_german2_ci NOT NULL,
  `agort` varchar(20) collate latin1_german2_ci NOT NULL,
  `agtel` varchar(20) collate latin1_german2_ci NOT NULL,
  PRIMARY KEY  (`id_ag`),
  UNIQUE KEY `id_vn` (`id_vn`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=207 ;

Gruß

• MyISAM, *würg*
• keine Referenz persdaten.arbeitgeber auf arbeitgeber - Tabelle
• der Trend geht ja zum Zweithandy, wie bildest Du das ab?
• Anzahl Kinder als varchar...

Andreas

 

[gurbelunder]

Allgemein sollte man hier im Sinne der Normalisierung neben der Arbeitgeber und der Persdaten Tabelle eine Verknüpfungstabelle erstellen, in der dann die Beziehung zwischen Arbeitgeber und Mitarbeiter hergestellt wird. So könne man auch den Ansatz verfolgen, dass ein Arbeitgeber mehrere Mitarbeiter aber ein Mitarbeiter nur einen Arbeitgeber hat, in dem man die ID des Arbeitgebers in der Verknüpfungstabelle jeweils nur einmal auftauchen lässt. Wäre durch einen Constraint wunderbar realisierbar:

Aber das Andreas wieder über MySQL meckert, war wieder klar

 

[akretschmer]

Allgemein sollte man hier im Sinne der Normalisierung neben der Arbeitgeber und der Persdaten Tabelle eine Verknüpfungstabelle erstellen, in der dann die Beziehung zwischen Arbeitgeber und Mitarbeiter hergestellt wird. So könne man auch den Ansatz verfolgen, dass ein Arbeitgeber mehrere Mitarbeiter aber ein Mitarbeiter nur einen Arbeitgeber hat, in dem man die ID des Arbeitgebers in der Verknüpfungstabelle jeweils nur einmal auftauchen lässt. Wäre durch einen Constraint wunderbar realisierbar:

Ja, aber ich kenne genug Leute mit 2 oder mehr Arbeitgebern. Zum Beispiel man hat noch einen Nebenjob.

Aber das Andreas wieder über MySQL meckert, war wieder klar

Hab MySQL gar nicht erwähnt ;-)

 

[ukulele]

Allgemein sollte man hier im Sinne der Normalisierung neben der Arbeitgeber und der Persdaten Tabelle eine Verknüpfungstabelle erstellen, in der dann die Beziehung zwischen Arbeitgeber und Mitarbeiter hergestellt wird. So könne man auch den Ansatz verfolgen, dass ein Arbeitgeber mehrere Mitarbeiter aber ein Mitarbeiter nur einen Arbeitgeber hat, in dem man die ID des Arbeitgebers in der Verknüpfungstabelle jeweils nur einmal auftauchen lässt. Wäre durch einen Constraint wunderbar realisierbar

Dann brauchst du keine Zwischentabelle sondern nur einen Fremdschlüssel auf Arbeitgeber in der Personentabelle.

Generell erkenne ich hier das Ziel nicht. Wie viele Arbeitgeber pro Kunde sind erlaubt, wie viele Kunden pro Arbeitgeber?

 

[exzel]

Also es muss nur ein Arbeitgeber pro Kunde erfasst werden. Das Arbeitgeberfeld darf aber auch leer bleiben. Wenn es mehrere sind wird nur der Hauptarbeitgeber erfasst. Letztlich ist die Maske Teil eines Auswertungsprogramm, in dem der Kunde seine Haushaltsausgaben und Einnahmen sieht.

Mir geht es hier um die Übung eine Tabelle in zwei aufzuteilen und die Befehle entsprechend zu gestalten. Aber es macht in dieser Konstellation keinen Sinn, oder?

Gruß

 

[akretschmer]

Also es muss nur ein Arbeitgeber pro Kunde erfasst werden. Das Arbeitgeberfeld darf aber auch leer bleiben. Wenn es mehrere sind wird nur der Hauptarbeitgeber erfasst. Letztlich ist die Maske Teil eines Auswertungsprogramm, in dem der Kunde seine Haushaltsausgaben und Einnahmen sieht.

Mir geht es hier um die Übung eine Tabelle in zwei aufzuteilen und die Befehle entsprechend zu gestalten. Aber es macht in dieser Konstellation keinen Sinn, oder?

Gruß

Das geht dann etwa so:

test=> create table arbeitgeber (id int primary key, name text);
CREATE TABLE
test=*> create table arbeitnehmer (id int primary key, arbeitgeber int references arbeitgeber, name text);
CREATE TABLE
test=*> insert into arbeitgeber values (1, 'arbeitgeber 1');
INSERT 0 1
test=*> insert into arbeitgeber values (2, 'arbeitgeber 2');
INSERT 0 1
test=*> insert into arbeitnehmer values (1, null, 'an 1 ohne arbeitgeber');
INSERT 0 1
test=*> insert into arbeitnehmer values (2, 1, 'an 2 mit arbeitgeber 1');
INSERT 0 1
test=*>

 

[ukulele]

Also es muss nur ein Arbeitgeber pro Kunde erfasst werden. Das Arbeitgeberfeld darf aber auch leer bleiben. Wenn es mehrere sind wird nur der Hauptarbeitgeber erfasst. [...]

Mir geht es hier um die Übung eine Tabelle in zwei aufzuteilen und die Befehle entsprechend zu gestalten. Aber es macht in dieser Konstellation keinen Sinn, oder?

Doch aber nur, wenn sich mehrere Kunden einen Arbeitgeber teilen können. Dazu hätte Kunde dann einen FK auf die Arbeitgebertabelle, kennen wir den Arbeitgeber nicht bleibt dieser leer. Wird ein neuer Arbeitgeber eingetragen muss natürlich erst geprüft werden, ob es diesen schon gibt bzw. die bestehenden Arbeitgeber müssten als Auswahl zur Verfügung stehen.

Weiter gedacht wird es brenzlig wenn die Kunden sich untereinander nicht kennen aber die selben Arbeitgeberstammdaten teilen. Selbst wenn das System nur im Hintergrund die Daten sinnvoll ablegen möchte (also aus 2 Eingaben durch Kunden einen Arbeitgeber erstellt weil es schlau genug ist zu erkennen, das es sich um den selben AG handelt) kann sich ja der Eintrag vieleicht ändern. Mal als Beispiel:

Kunde A füllt Formular aus, Name A, Arbeitgeber X
Kunde B füllt Formular aus, Name B, Arbeitgeber X
System erkennt das AG von A und B identisch sind, erstellt also im Falle von Kunde B nur einen Verweis auf den bereits existierenden AG X
Kunde B ändert später die Adresse von AG X
Kunde A hat eine geänderte Adresse des AG und das System kann das nichtmehr auseinander halten

In einem solchen Fall macht es fast keinen Sinn die Daten zu zerlegen. Die Wikipedia hat ähnliche Probleme, eine Änderung betrifft nicht nur den eigenen Account sondern alle also müssen diese nachvollzogen werden und niemand darf wilkürliche Änderungen vollziehen.

 

[exzel]

@akretschmer

Funktioniert das auch unter MyISAM?

Ich habe die Tabellen mit deinen Befehlen angelegt. Unter phpmyadmin konnte ich aber in der arbeitnehmertabelle die Schlüssel der Spalte arbeitgeber abändern wie ich wollte. Ich konnte auch Werte zuweisen, die in der Arbeitgebertabelle nicht vorhanden waren?

Darf das sein?

Gruß

 

[exzel]

@ukulele

Hm, da hast du ein fehlendes Puzzlestück erwähnt. Die Kunden kennen sich nicht untereinander. Dann macht die Trennung der Tabellen doch keinen Sinn, oder? Auch wenn das Arbeitgeberfeld freiwillig ist.

Gruß

 

[akretschmer]

@akretschmer

Funktioniert das auch unter MyISAM?

Ich habe die Tabellen mit deinen Befehlen angelegt. Unter phpmyadmin konnte ich aber in der arbeitnehmertabelle die Schlüssel der Spalte arbeitgeber abändern wie ich wollte. Ich konnte auch Werte zuweisen, die in der Arbeitgebertabelle nicht vorhanden waren?

Darf das sein?

Gruß

Mit MyISAM gar nicht. es geht mit InnoDB, aber darfst die Constraints nicht inline definieren, sondern extra als foreign keys.
(MySQL akzeptiert hier alles (da gemäß SQL-Norm alles okay ist), wirft keine Fehler, und kümmert sich nicht weiter drum.)


MyISAM kann faktisch überhaupt nichts. InnoDB a bissl was. Ist bei MySQL das derzeit kleinste Übel.



Willkommen in der lustigen Welt von MySQL. Sie ist voller Überraschungen ...

 

[exzel]

Ok, dann müsste also bei InnoDB eine Fehlemeldung erscheinen, sobald ich in der Arbeitnehmertabelle Werte hinterlege, die nicht in der Arbeitgebertabelle vorhanden sind, richtig? Mit welcher DB programmierst du?