Kundendaten anlegen oder gleich in DB schreiben?

[AllesSelberMachen]

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]

Hallo,

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]

Hallo,

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

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]

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]

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]

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]

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]

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]

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!