MySQL Datenbank für Zahlungsarten

Ja so meinte ich es und mit der Änderung des Begriffes hast du recht, deswegen habe ich das Kennzeichen, welches immer gleich bleibt. wenn z. B. aus Lastschrift mal Lastschrifteinzug wird, dann is das Kennzeichen trotzdem LASTSCHRIFT und bleibt auch immer so. Erhöht ja auch die Lesbarkeit im Code, als wenn ich die id nehmen würde

das ist aber totaler Schwachsinn. Du hast bereits einen Primärschlüssel (id) um die Zahlungsart zu identifizieren, dann brauchst du nicht noch einen String um den Anzeigenamen der Zahlungsart zuzuordnen.
Wenn dann musst du die id entfernen und deinen String zum Primärschlüssel machen, so hast du einfach aber einen total sinnloses id-Attribut.
 
Wenn dann musst du die id entfernen und deinen String zum Primärschlüssel machen, so hast du einfach aber einen total sinnloses id-Attribut.

Warum is das sinnlos? Wenn im Code steht

PHP:
if ($row['id'] == 1)

dann is doch
PHP:
if ($row['kennzeichen'] == 'LASTSCHRIFT')

viel besser zu lesen und ich weiß sofort um was es geht.
 
Wenn man da nun wirklich Konstanten im Code definiert darf man ja immer im Code Änderungen vornehmen, wenn man eine neue Zahlungsart einträgt - doof, oder?
Und? Unterschiedliche Zahlungsarten haben unterschiedliche Daten und somit wird immer ne Fallunterscheidung nötig. Somit kommt man um die Änderung im Code auch nicht drumrum.

Wenn im Code steht

PHP:
if ($row['id'] == 1)

dann is doch
PHP:
if ($row['kennzeichen'] == 'LASTSCHRIFT')

viel besser zu lesen und ich weiß sofort um was es geht.
... aber fehleranfälliger und aufwändiger, weswegen niemand so programmiert (außer unsere Lose-Kiddies natürlich :ugly:).

Um es besser lesbarer zu haben, nutzt du ja die Konstante (das is zumindest einer der Gründe).
 
dann is doch
PHP:
if ($row['kennzeichen'] == 'LASTSCHRIFT')

viel besser zu lesen und ich weiß sofort um was es geht.

Stimmt, das ist besser zu lesen. Aber dann wäre LASTSCHRIFT eher dein PrimaryKey für deine Zahlungstypentabelle und keine zusätzliche numerische ID.


Eventuell sollte man das aber anders angehen.
Weg davon, dass du eine große if-Abfrage machst, überprüfst was ausgewählt wurde und dann den speziellen Code ausführst.


Solltest du das Objektorientiert realisieren, könnte man das über ein Interface lösen, welches die generellen Methoden / Hooks von Zahlungstypen definiert und dann in der Zeile für einen Zahlungstyp den Namen der Klasse einträgt und diese dann nur noch erstellst.

PHP:
interface Zahlungstyp { ... }

class ZahlungstypLastschrift implements Zahlungstyp { ... }

// Nach dem Auslesen aus deiner Bestelltabelle, anstatt dem ganzen if-Konstrukt:

$zahlungstyp = new $row['zahlungstypKlasse'];
$zahlungstyp->onBestellung(/* eventuell allgemeine Parameter, z.B. die Zeile aus der Bestellungstabelle */ $bestellung);

Ohne Objektorientierung:
Ich weiß zwar nicht was man allgemein von soetwas hält.. aber eine Möglichkeit wäre für jeden Zahlungstyp eine Funktion zu definieren. Z.B.:
PHP:
function zahlungstypLastschriftBestellung() { ... }

...

$row['zahlungstypFunktion'](/* eventuell allgemeine Parameter, z.B. die Zeile aus der Bestellungstabelle */ $bestellung);

Dies hier wäre für mich so eine halbe Vorstufe zu sauberem OOP mit Hooks u.ä.



Bei beiden Sachen müsstest du dann eine Verbindung zwischen deine Bestelltabelle und dem Zahlungstyp (anhand der numerischen ID! Identifier wie 'LASTSCHRIFT' ist nicht nötig) beim Auslesen erstellen, da du den Klassennamen / Funktionsnamen auslesen musst ;)



Und theHacker: Aber wenn er dann eine Konstante erstellt und da die ID als Wert nimmt.. ist das nicht doof, sobald mal die Zahlungstypen z.B. in anderer Reihenfolge in der Datenbank gespeichert werden? Oder man - je nachdem wie weit das System geht / erweitert wird / ... - über ein Plugin variabel die Zahlungstypen nachladen kann?
Eine Verbindung zwischen einer variablen ID (welches ja bei AUTO_INCREMENT der Fall ist) in der Datenbank und einer Konstante im Code finde ich total unschön. Da wäre es schon besser einen festen Identifier, wie baserider 'LASTSCHRIFT' benutzt hat, zu benutzen. Den dann eventuell als Konstantenwert.. aber nicht die, mittels AUTO_INCREMENT o.ä. erzeugte, ID zu verwenden.

EDIT:
da geb ich dir recht, aber ich muss eben immer die Werte der Konstanten synchron halten zur Datenbank.
Ja, das meine ich hier unten.
 
da geb ich dir recht, aber ich muss eben immer die Werte der Konstanten synchron halten zur Datenbank.
Nö. Der Primärschlüssel in der DB is numerisch, so is deine Konstante. Du musst sie nur ergänzen, wenn was dazukommt; aber das hab ich ja schon 2- oder 3mal gepostet, dass du diesen Aufwand so oder so hast.
Auch blick ich ned, was sich an Zahlungsmethoden ändern soll. Die werden einmal programmiert und dann tut sich da nie wieder was.

Und theHacker: Aber wenn er dann eine Konstante erstellt und da die ID als Wert nimmt.. ist das nicht doof, sobald mal die Zahlungstypen z.B. in anderer Reihenfolge in der Datenbank gespeichert werden?
In einer Datenbank existiert grundsätzlich keine Reihenfolge, auch wenn einen z.B. MySQL das Glauben machen will, weil die Werte immer in derselben Reihenfolge rauskommen. Das is "Zufall" und man kann und darf(!) sich nicht darauf verlassen.

AutoIncrement is in diesem Fall unangebracht, weil die Tabelle mit den Zahlungsmitteln nicht geändert wird. Wenn Plugins, dann definieren die eben eine zusätzliche Konstante, die Fallunterscheidung kommt in einer neuen Klasse rein und in der DB gibts für die Daten ne neue Tabelle.
 
In einer Datenbank existiert grundsätzlich keine Reihenfolge, auch wenn einen z.B. MySQL das Glauben machen will, weil die Werte immer in derselben Reihenfolge rauskommen. Das is "Zufall" und man kann und darf(!) sich nicht darauf verlassen.

Hm ja. Ich meinte nun falls man mal das neu installiert und dann in einer anderen Reihenfolge die Zeilen einträgt.. bei AUTO_INCREMENT wäre das dann ein Problem. Also das muss dann auf jeden Fall aus.. ja.. aber erschwert auch wieder wenn man später was hinzufügen möchte per Script, da man dann erst eine ID finden muss oder wie man das dann auch immer mit den IDs regeln möchte. Ich finde man sollte alles so programmieren, dass man es möglichst leicht erweitern kann. Und gerade bei Zahlungsarten kann es immer mal sein, dass man PayPal oder was auch immer später noch aufnimmt..
 
[...]aber erschwert auch wieder wenn man später was hinzufügen möchte per Script, da man dann erst eine ID finden muss [...] Und gerade bei Zahlungsarten kann es immer mal sein, dass man PayPal oder was auch immer später noch aufnimmt..
Und was musst du da jetzt für ne ID "finden"? Wenn du 1 für Rechnung und 2 für Bankeinzug hast, dann nimm eben die 3 für PayPal. Bei ner INT-Spalte bleiben dir dann immer noch 4.294.967.292 weitere Zahlungsmöglichkeiten.
Ich bin sehr neugierig, wie du die alle ausnutzen willst
rofl.gif


Es ist halt neu für mich, das man die ID's der DB fest im Quellcode als Konstantenwerte reinschreibt.
Es gibt eben immer Sachen, die für einen neu sind. Wenn man es sicher aber dann hat sagen lassen, wie es geht, weiß man es für die Zukunft.

Apropos für die Zukunft wissen: Deppenapostrophen macht man nicht ;) :p
 
Code:
<Datei Konstanten>
define('Bar',0);
define('überweisung',1);
define('paypal',2);
...

Code:
<php datei>

switch (zahlungs_id) {
  case Bar : .. break;
  ...
  case paypal : ... break;
}

wäre das nicht simpel zu nutzen ?
da brauch man nur die zahlungs_id aus der tabelle
 
statt eine Konstante zu pflegen musst du jedesmal auch eine neue if-Bedingung in den Code einbauen, mit deinem String.

Die Konstante nur ein mal zu pflegen ist mir klar, aber das hat doch nix damit zu tun, das ich immer ne neue if-Bedingung einbauen muss. Wenn ich die Bedingung brauche baue ich sie ein, ob nun eine Konstante oder ein String als Vergleichswert steht is doch dabei egal.
 
Wenn ich die Bedingung brauche baue ich sie ein, ob nun eine Konstante oder ein String als Vergleichswert steht is doch dabei egal.

Hm.. die Problematik bei dem Benutzen von Strings ist, dass du schnell mal einen Tippfehler nicht siehst und dann lange brauchst bis du diesen dann doch siehst. Wenn du dir allgemein angewöhnst so etwas über Konstanten zu lösen, merkst du, falls du da eine nicht existente Konstante aufrufst (solange das/der[?!] ErrorLevel stimmt).. und ist ein Vergleich mit Zahlen im allgemeinen besser / effektiver / schneller / ....
 
Wer mal Assembler programmiert hat, weiß, wie teuer ein String-Vergleich im Gegensatz zu einem Integer-Vergleich is. - das nur zu den Performance-Gründen.
Wichtiger is auf jeden Fall, dass der Code ordentlich und sauber bleibt.
 
Hm.. die Problematik bei dem Benutzen von Strings ist, dass du schnell mal einen Tippfehler nicht siehst und dann lange brauchst bis du diesen dann doch siehst. ....

Das leuchtet mir auch ein, nur ich verstehe nicht warum ich jedesmal eine neue if-bedingung verwenden muss, wenn man strings verwendet. Wenn ich Konstanten verwende muss ich genauso if-bedingungen verwenden. Die Verwendung von if-Bedingungen hängt doch nicht davon ab ob ich Konstanten oder Strings verwende sondern vom zu lösenden Problem.
 
es ging mir nur um dein Argument, du müsstest die Konstanten extra pflegen, da du aber sowieso für jede neue Zahlungsart eine If-Bedingung anlegen musst, taugt das Argument nichts, du musst sowieso den Code anpacken.
 
Naja, ich mag am liebsten noch so Ansätze wie ich vorgeschlagen habe.
Da muss man - je nachdem wie man es realisiert - nur eine Funktion definieren und dann läuft das..

@ice-breaker: Wie sieht das eigentlich allgemein aus, wenn man so etwas mittels dynamischem Funktionsaufruf macht? Verwerflich oder ist soetwas in Ordnung? (natürlich nur vom Standpunkt, dass man auf OOP verzichtet)