Rechnungsmodul

shoq · 03.03.2009, 08:40

Hallo Leute.

Ich bin gerade dabei ein Rechnungssystem (mit Rechnungen, dazu Positionen usw.) in PHP und MySQL zu schreiben. Dabei sollen Rechnungen in MySQL gespeichert werden und über PHP eingetrage, verändert, angesehen, als bezahlt markiert usw. werden.

Programmiertechnisch ist das alles keine große Sache. Habe in Java OOP gelernt und zu PHP gibts da ja jetzt nicht so große Unterschiede.
Nur strukturell bin ich mir noch nicht ganz im klaren wie ich das Ganze am besten umsetze.

Momentane Idee ist die Rechnungen, Positionen etc. in MySQL zu speichern (auch mit Generalisierung/Spezialisierung) und über Klassen alle Abfragen, Inserts usw. zu regeln, weil MySQL ja schneller arbeitet als PHP (?).
Bspw.:

Code:

$rechnungen->getRechnungenByTyp("wiedervk"); 

$rechnungen->insert($betrag,$typ);

usw.

Ist das optimal oder gibt es da noch bessere Lösungsansatze? Z.B. alle Rechnungen als Objekte der Klasse Rechnungen behandeln?
Was haltet ihr von Propel?

Propel - Trac

Vielen Dank schonmal für eure Anregungen.
Gruß Ron

Chriz · 03.03.2009, 11:34

Hallo,
ich verstehe so einige Aussagen nicht

Zitat:

Momentane Idee ist die Rechnungen, Positionen etc. in MySQL zu speichern (auch mit Generalisierung/Spezialisierung) und über Klassen alle Abfragen, Inserts usw. zu regeln, weil MySQL ja schneller arbeitet als PHP (?).

Inwiefern ist hier schneller relevant? Daten gehören in die Datenbank und Logik in die Applikation. Bei MySQL auf jeden Fall wichtig die innoDB Engine zu verwenden, die unterstützt Transaktionen.

Zitat:

Z.B. alle Rechnungen als Objekte der Klasse Rechnungen behandeln?

Wie sonst?

Zitat:

$rechnungen->getRechnungenByTyp("wiedervk");

$rechnungen->insert($betrag,$typ);

Benutz lieber Einzahl, das ist verständlicher:

PHP-Code:

  <?php
$invoice->insert($amount, $type);
?>

und halte dich an Konventionen, z.B. nur Englisch benutzen, nur Einzahl für Klassen, benutz Konstanten für Typen (statt "wiedervk" lieber Invoice::TypeXy), ..

Ein ORMapper ist sicherlich ein sehr guter Schritt, auch wenn ich Propel nicht so mag.

shoq · 03.03.2009, 12:10

Zitat:

Zitat von Chriz

Hallo,
ich verstehe so einige Aussagen nicht

Inwiefern ist hier schneller relevant? Daten gehören in die Datenbank und Logik in die Applikation. Bei MySQL auf jeden Fall wichtig die innoDB Engine zu verwenden, die unterstützt Transaktionen.

Ich habe im Moment ein bestehendes System in dem nahezu alles prozedual entwickelt wurde. Es gibt lediglich eine Klasse für DB-Zugriffe. Für mich ist OOP in diesem Fall aber sinniger, weil es einfacher zu erweitern, verwalten, verstehen, logischer etc. ist. Deswegen soll das bestehende System nun schrittweise auf OOP umgestellt werden, was ein einziger Krampf wird, weil die Tabelle voll mit Redundanzen etc. sind.

Im Moment sind es ca. 7000 Rechnungen die verwaltet werden. D.h. wenn ich mir alle Rechnungen ausgeben lasse, dauert das schonmal seine Zeit.

Was ich nicht ganz verstehe ist, bei welchen Daten es sinnvoll wäre, diese in Objekte zu packen. Wenn ich jetzt an das Beispiel Rechnungen denke:

Es müssen neue Rechnungen angelegt werden (Formular) und dieses neu angelegte Objekt muss dann nochmal extra in die Datenbank gespeichert werden, was ja irgendwie "doppelt gemoppelt" ist.

Zitat:

Benutz lieber Einzahl, das ist verständlicher:

PHP-Code:

  <?php
$invoice->insert($amount, $type);
?>

und halte dich an Konventionen, z.B. nur Englisch benutzen, nur Einzahl für Klassen, benutz Konstanten für Typen (statt "wiedervk" lieber Invoice::TypeXy), ..

Ein ORMapper ist sicherlich ein sehr guter Schritt, auch wenn ich Propel nicht so mag.

Deine Tipps zur Benennung werd ich mir mal zu Herzen nehmen. Auch weil das System später mehrsprachig werden soll.

Was kannst du mir denn als Alternative zu Propel empfehlen?

Danke schonmal. Hast mich ein ganzes Stück weiter gebracht.

erc · 03.03.2009, 22:28

Du hast glaub ich ein Denkfehler. Du darfst nicht versuchen die Objekte in der Datenbank zu speichern, sondern die Objekte müssen die Daten in der Datenbank speichern. Sprich deine Klasse Rechnung sollte am Ende nix anderes sein als ein OR Mapper.

Chriz · 04.03.2009, 01:00

Zitat:

Zitat von shoq

Ich habe im Moment ein bestehendes System in dem nahezu alles prozedual entwickelt wurde. Es gibt lediglich eine Klasse für DB-Zugriffe. Für mich ist OOP in diesem Fall aber sinniger, weil es einfacher zu erweitern, verwalten, verstehen, logischer etc. ist. Deswegen soll das bestehende System nun schrittweise auf OOP umgestellt werden, was ein einziger Krampf wird, weil die Tabelle voll mit Redundanzen etc. sind.

Du musst vorher auf jeden Fall abwaegen, ob ein komplettes Re-Factoring lohnt, das kann schon ein enormer Mehraufwand sein. Fuer kleine Aenderungen sollte man sich ueberlegen, nicht den Dirty-Style des bestehenden Projektes zu uebernehmen. Kommt immer darauf an, was man sich als Ziel setzt (langfristig guter Code, schnelle Loesung des Problems, ..)

Zitat:

Im Moment sind es ca. 7000 Rechnungen die verwaltet werden. D.h. wenn ich mir alle Rechnungen ausgeben lasse, dauert das schonmal seine Zeit.

Ueblicherweise gibst du ja nicht alle Rechnungen auf einmal aus - das solltest du seitenweise unterteilen. Dann ist die Anzahl praktisch egal.

Zitat:

Was ich nicht ganz verstehe ist, bei welchen Daten es sinnvoll wäre, diese in Objekte zu packen. Wenn ich jetzt an das Beispiel Rechnungen denke:

Es müssen neue Rechnungen angelegt werden (Formular) und dieses neu angelegte Objekt muss dann nochmal extra in die Datenbank gespeichert werden, was ja irgendwie "doppelt gemoppelt" ist.

Wie das mein Vorredner schon gesagt hat, du persistierst die Daten ja nicht in einem Objekt, sondern die Daten bleiben natuerlich nur in der Datenbank. In ein Objekt werden sie ja nur als Quasi-Kopie geladen. Insofern lohnt sich das Anlegen von Klassen fuer Datenbank-Tabellen/Eintraege sicherlich, da hier keine wirkliche Redundanz entsteht, sondern vielmehr eine abstrakte Zugriffsform.

Zitat:

Deine Tipps zur Benennung werd ich mir mal zu Herzen nehmen. Auch weil das System später mehrsprachig werden soll.

Wenn du dein System im MVC-Muster aufbaust, wirst du relativ wenig Probleme damit haben, da Model und Controller von der Sprache relativ unbeeindruckt sind.

Zitat:

Was kannst du mir denn als Alternative zu Propel empfehlen?

Ich weiss schon nicht mehr was mir an Propel und Konsorten nicht gefallen hat, ich glaube der Deklarationsoverhead, aber das ist wirklich nur eine personeliche Meinung. Ich verwende das Zend Framework und dabei das - wie heisst es: das Table Gateway Interface zum Zugriff auf die Datenbank. Frag mich nicht was da so konkret der Unterschied ist. Fuer mich ist es komfortabel weil ich die Zend_Db Klasse schon kenne. Da muss jeder fuer sich das richtige finden.

shoq · 04.03.2009, 08:14

Zitat:

Zitat von erc

Du hast glaub ich ein Denkfehler. Du darfst nicht versuchen die Objekte in der Datenbank zu speichern, sondern die Objekte müssen die Daten in der Datenbank speichern. Sprich deine Klasse Rechnung sollte am Ende nix anderes sein als ein OR Mapper.

PHP-Code:

  $select = "SELECT id, beleg_nr, rg_nr, eingangsdatum, rg_datum FROM rechnungen";

$db->query($select);
        for ($i = 0; $i < $db->num_rows(); $i++) {
        #for ($i = 0; $i < 20; $i++) {
                $db->movenext();
                $bill[]    = $db->row;    
                
                $bills[] = new Bill($bill[$i]['id'], $bill[$i]['beleg_nr'],  $bill[$i]['rg_nr'], $bill[$i]['eingangsdatum'], $bill[$i]['rg_datum']);
        }

PHP-Code:

  class Bill {
    private $id;
    private $document_number; 
    private $entrydate;            
    private $billingdate;
    private $bills_no;
        private $amount;

    public function __construct($id, $document_number, $bills_no, $entrydate, $billingdate) {
        $this->id = $id;
        $this->document_number = $document_number;
        $this->bills_no = $bills_no;
        $this->entrydate = $entrydate;
        $this->billingdate = $billingdate;
    }

    public function insert($amount) {
$this->amount = $amount;

        global $db;

        $insert = 'INSERT INTO rechnungen betrag = ' . $amount . ' WHERE id = '. $this->id .'';

        $db->query($insert);
    }
    
}

So hab ich eine Kopie der Rechnung aus der Datenbank und kann diese über insert mit einem Betrag füllen. Ist der Denkansatz so richtig?

Zitat:

Zitat von Chriz

Du musst vorher auf jeden Fall abwaegen, ob ein komplettes Re-Factoring lohnt, das kann schon ein enormer Mehraufwand sein. Fuer kleine Aenderungen sollte man sich ueberlegen, nicht den Dirty-Style des bestehenden Projektes zu uebernehmen. Kommt immer darauf an, was man sich als Ziel setzt (langfristig guter Code, schnelle Loesung des Problems, ..)

Es soll insgesamt auf langfristig guten Code hinauslaufen. Die Erweiterbarkeit ist hierbei extrem wichtig.

Zitat:

Zitat von Chriz

Ueblicherweise gibst du ja nicht alle Rechnungen auf einmal aus - das solltest du seitenweise unterteilen. Dann ist die Anzahl praktisch egal.

Wie das mein Vorredner schon gesagt hat, du persistierst die Daten ja nicht in einem Objekt, sondern die Daten bleiben natuerlich nur in der Datenbank. In ein Objekt werden sie ja nur als Quasi-Kopie geladen. Insofern lohnt sich das Anlegen von Klassen fuer Datenbank-Tabellen/Eintraege sicherlich, da hier keine wirkliche Redundanz entsteht, sondern vielmehr eine abstrakte Zugriffsform.

Wenn du dein System im MVC-Muster aufbaust, wirst du relativ wenig Probleme damit haben, da Model und Controller von der Sprache relativ unbeeindruckt sind.

Danke. Dann werd ich mich mit diesem Thema wohl nochmal ausführlich auseinandersetzen müssen.

Zitat:

Zitat von Chriz

Ich weiss schon nicht mehr was mir an Propel und Konsorten nicht gefallen hat, ich glaube der Deklarationsoverhead, aber das ist wirklich nur eine personeliche Meinung. Ich verwende das Zend Framework und dabei das - wie heisst es: das Table Gateway Interface zum Zugriff auf die Datenbank. Frag mich nicht was da so konkret der Unterschied ist. Fuer mich ist es komfortabel weil ich die Zend_Db Klasse schon kenne. Da muss jeder fuer sich das richtige finden.

Werds mir auf jeden Fall mal anschauen.

Danke nochmals für eure Hilfe. Jetzt geht das große Schmökern los. :>

Chriz · 04.03.2009, 14:45

Das global ist nicht gut, gib das Datenbankobjekt im Konstruktor mit, dann siehts ganz gut aus.

shoq · 04.03.2009, 15:06

Zitat:

Zitat von Chriz

Das global ist nicht gut, gib das Datenbankobjekt im Konstruktor mit, dann siehts ganz gut aus.

Schau mir gerade CakePHP an. Bisher gefällts mir schonmal ganz gut.
Trotzdem danke für den Tipp.

dr.e. · 04.03.2009, 21:11

Zitat:

Was kannst du mir denn als Alternative zu Propel empfehlen?

Vielleicht das hier? Die Komponente ist IMHO deutlich mächtiger als die üblichen Table-Data-Gateway-Implementierungen und ermöglicht dir ein komplexes Datenbankdesign einfach abzubilden.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

03.03.2009, 08:40
shoq Neuer Benutzer Registriert seit: 03.03.2009 Beiträge: 11	Rechnungsmodul Hallo Leute. Ich bin gerade dabei ein Rechnungssystem (mit Rechnungen, dazu Positionen usw.) in PHP und MySQL zu schreiben. Dabei sollen Rechnungen in MySQL gespeichert werden und über PHP eingetrage, verändert, angesehen, als bezahlt markiert usw. werden. Programmiertechnisch ist das alles keine große Sache. Habe in Java OOP gelernt und zu PHP gibts da ja jetzt nicht so große Unterschiede. Nur strukturell bin ich mir noch nicht ganz im klaren wie ich das Ganze am besten umsetze. Momentane Idee ist die Rechnungen, Positionen etc. in MySQL zu speichern (auch mit Generalisierung/Spezialisierung) und über Klassen alle Abfragen, Inserts usw. zu regeln, weil MySQL ja schneller arbeitet als PHP (?). Bspw.: Code: $rechnungen->getRechnungenByTyp("wiedervk"); $rechnungen->insert($betrag,$typ); usw. Ist das optimal oder gibt es da noch bessere Lösungsansatze? Z.B. alle Rechnungen als Objekte der Klasse Rechnungen behandeln? Was haltet ihr von Propel? Propel - Trac Vielen Dank schonmal für eure Anregungen. Gruß Ron Geändert von shoq (03.03.2009 um 08:50 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

03.03.2009, 22:28
erc Erfahrener Benutzer Registriert seit: 02.01.2009 Beiträge: 730 PHP-Kenntnisse: Fortgeschritten	Du hast glaub ich ein Denkfehler. Du darfst nicht versuchen die Objekte in der Datenbank zu speichern, sondern die Objekte müssen die Daten in der Datenbank speichern. Sprich deine Klasse Rechnung sollte am Ende nix anderes sein als ein OR Mapper.

04.03.2009, 14:45
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	Das global ist nicht gut, gib das Datenbankobjekt im Konstruktor mit, dann siehts ganz gut aus.