# Kundendaten anlegen oder gleich in DB schreiben?



## AllesSelberMachen (5. Mai 2008)

Moins,

Ich habe eine Datenbank mit name,vorname,kontonummer,betrag. Wenn ich nun einen Kunden neu anlege, frage ich mich ob ich erst ein neues Kundenobjekt erstellen sollte von meiner Kunden.java Klasse oder ob  es nicht schneller geht den Kunden (name, vorname, kontonummer(ist primary key da eindeutig und wird fortlaufend gezählt , kann ja mehrere michael müller geben...) einfach in die Datenbank zu schreiben?


----------



## kama (5. Mai 2008)

Hallo,



			
				AllesSelberMachen hat gesagt.:
			
		

> kontonummer(ist primary key da eindeutig und wird fortlaufend gezählt , kann ja mehrere michael müller geben...) einfach in die Datenbank zu schreiben?


1. Fachliche Schlüssel sollten niemals als PK in der DB genutzt werden. Dafür gibt es sog. Sequences etc. in der DB selbst.
2. Neues Objekt in der DB anlegen und fertig....und damit arbeiten...

MfG
Karl Heinz Marbaise


----------



## AllesSelberMachen (5. Mai 2008)

kama hat gesagt.:
			
		

> Hallo,
> 
> 
> 
> ...



1.)fachliche schlüssel??? Naja die Kontonummer ist das einzige beim Kunden was eindeutig ist. Beim jedem anlegen eines Kunden in der mysql db wird eine kontonummer hochgezählt.

2.) was meinst du mit neues Objekt in der DB anlegen? meinst du ich soll einfach den namen+vornamen in die Kundentabelle inserten?


----------



## AllesSelberMachen (10. Mai 2008)

kama hat gesagt.:
			
		

> 2. Neues Objekt in der DB anlegen und fertig....und damit arbeiten...
> 
> MfG
> Karl Heinz Marbaise



neues Objekt in DB anlegen gemäß dem Bild?

http://www.galileocomputing.de/open...lein/kleinkap_activerecord/objekte-zeilen.gif

ist zwar ruby aber egal... sprich ich habe eine Instanz einer Klasse und schreibe das Objekt in die Tabelle hinein?


----------



## foobar (10. Mai 2008)

> 1. Fachliche Schlüssel sollten niemals als PK in der DB genutzt werden. Dafür gibt es sog. Sequences etc. in der DB selbst.


Warum sollte man das nicht machen? Und was ist, wenn man sichergehen kann, daß der fachliche Schlüssel unique ist?


----------



## tfa (10. Mai 2008)

> Warum sollte man das nicht machen? Und was ist, wenn man sichergehen kann, daß der fachliche Schlüssel unique ist?


Fachliche Schlüssel können sich ändern und haben deswegen als PKs in der Datenbank nichts zu suchen.


----------



## AllesSelberMachen (13. Mai 2008)

tfa hat gesagt.:
			
		

> > Warum sollte man das nicht machen? Und was ist, wenn man sichergehen kann, daß der fachliche Schlüssel unique ist?
> 
> 
> Fachliche Schlüssel können sich ändern und haben deswegen als PKs in der Datenbank nichts zu suchen.



Die Kontonummer ändert sich nie, wenn dann wird ein neues KOnto angelegt und das alte gelöscht, so läufts bei der Bank.


----------



## maki (13. Mai 2008)

> Die Kontonummer ändert sich nie, wenn dann wird ein neues KOnto angelegt und das alte gelöscht, so läufts bei der Bank.


Ja, klar, wie oft ich das schon gehört habe... auch ganz oben auf der Liste: "Dieses Feld ist eindeutig (unique)...", 2 Monate später dann: "Aber mehrere Datensätze können da denselben Wert haben..."

Keine Bank wird die Kontonummer als PK haben.

So etwas macht man nicht (mehr), viel zu inflexibel.


----------



## VoiDee (13. Mai 2008)

Auch wenn's sich nicht immer gleich erschliesst. Nimm die Kontonummer nicht als PK. Nimm besser einen Sequencenwert oder (noch besser) erzeuge eine zufällige eindeutige Nummer. Später - wirst du dankbar sein - deinen PK nicht an einen fachlichen Wert gebunden zu haben.
Sei froh, dass du dann einen weiteren eindeutigen Wert in der DB hast.

Der kluge Programmierer sorgt vor!


----------

