Zeiterfassung + Rechnungserstellung (netzwerkfähig)

[DelphiManiac]

Hallo,

ich soll für einen Kunden eine Zeiterfassung:
-> Welcher Mitarbeiter hat wie lange an etwas gearbeitet
erstellen, diese erfassten Zeiten sollen dann in einer Rechnungserstellung münden.

Meine Frage an euch:
Das ganze sollte netzwerkfähig sein, dass heißt es gibt eine Datenbank, die die Datensätze abspeichert.
Diese liegt dann auf dem Server, bis hier hin alles klar, nun sollen die Mitarbeiter ihre Daten erfassen können, diese
Datensätze müssten dann in der DB gespeichert werden. Aus diesen Datensätzen sollte das Controlling dann die Möglichkeit
haben die Rechnung als Word-Dokument zu generieren.

Ist dort Delphi + DB die beste Wahl, wenn ja welche Datenbank würde hier gut passen? MySQL / Access / Paradox??
Und falls nein, welche Technologie ist die bessere Wahl? Access (als DB + Frontend)

Danke schonmal für eure (hoffentlich reichliche) Kommentare und Hilfestellungen...

Gruß DelphiManiac

[mkinzler]

Zitat:

ist dort Delphi + DB die beste Wahl,

Ja.

Zitat:

wenn ja welche Datenbank würde hier gut passen? MySQL / Access / Paradox??

Keines der 3. Ich würde FireBird, MSSql 2005 express, Oracle Express, DB2 express.

[Der_Unwissende]

Zitat von DelphiManiac:

Ist dort Delphi + DB die beste Wahl, wenn ja welche Datenbank würde hier gut passen? MySQL / Access / Paradox??
Und falls nein, welche Technologie ist die bessere Wahl? Access (als DB + Frontend)

Hi, was die Datenbanken angeht, so gebe ich mkinzler völlig recht, die von Dir vorgeschlagenen DBMS haben ein paar Nachteile. Access ist einfach mal gaaanz schlecht (kannst die Gründe nachlesen, wenn Du einfach mal nach Access suchst, würde mich wundern wenn man die nicht schnell findet). MySQL hat (afaik) ein merkwürdiges Lizenzmodell und es gibt einfach gute Alternativen.
Die "großen" wie Oracle und IBM stellen ihre Datenbanken in freien Versionen zur Verfügung, die recht geringen Beschränkungen (so in der Richtung <= 4 GByte RAM und nur 1 CPU) zur Verfügung. Hier hast Du den Vorteil, dass Du sehr einfach skalieren kannst (kaufst einfach das vollwertige System) und wirklich ein Produkt bekommst, dass den aktuellem Standard entspricht (gilt nicht nur für die!).
Firebird oder PostgreSQL sind gleich ganz frei und bieten auch einiges (Firebird dabei ein wenig mehr).

Was Delphi+DB und vielleicht auch ganz generell die Wahl der DB betrifft, so gibt es einen ganz wichtigen Punkt, den Du berücksichtigen solltest, um die Frage der "besten Wahl" zu beantworten. An sich lautet die klare Antwort, dass es keine objektiv beste Wahl gibt. Der Punkt den Du berücksichtigen musst ist, was für Wissen steht Dir überhaupt zur Verfügung. Wenn ich jetzt sage Java + DB ist die allerbeste Wahl ever!!!! Dann würdest Dein Produkt dass nicht bestätigen, wenn Du gar kein Java beherrscht. Selbst wenn Du Dich einarbeitest dürfte das Produkt (wenn es das erste in Java ist) dann eher hinter den Möglichkeiten der Sprache bleiben. Das gleiche gilt für die DB. Wichtig ist die Frage, was es für Anforderungen gibt.
Verwendet die Firma schon ein DBMS? Dann haben die sicher auch Leute die sich mit dem auskennen und das hat dann Vorteile (dann sollte ganz klar dieses DBMS bevorzugt werden). Ist dies nicht der Fall, solltest Du das DBMS nehmen, mit dem Du erwartest am Besten klar zu kommen. Wenn ein DBMS Dir immens viele tolle Feature bietet, die Du alle nicht nutzen kannst und Du wegen der Komplexität ein sehr schlechtes System erstellst, hängt das jeder (theoretisch) schlechteren DB auf einem anderen System, das Du optimieren kannst hinterher.
Das gleiche gilt halt auch für die verwendete Programmierung. Bist Du ein Crack in VBA, muss das nicht schlechter sein als Delphi (ok, schlechtes Beispiel was?! ).

Jedenfalls reicht es hier aus, dass Du eine Sprache und die richtigen Konzepte beherrscht um eine gute Lösung zu erstellen. Dabei muss es nicht die Beste sein (wäre schwer möglich das dann auch zu zeigen) und selbst dann gäbe es andere die genauso gut sind. Deshalb einfach auf eine machbare Lösung konzentrieren, mit der der Kunde zufrieden ist, das reicht doch für's Erste.

Gruß Der Unwissende

[SirTwist]

Die Wahl der SQL-Datenbank ist hier wohl eher nebensächlich, da es sich wirklich nur um recht einfach gestrickte Daten handelt.

Wichtiger ist eigentlich da die Wahl der Zugriffsrechte, denn ein Mitarbeiter sollte doch wohl nur seine eigenen Daten sehen und ändern können und nicht die der anderen. Natürlich könntest Du das über die Programmlogik abfangen, aber dann nimmt man einfach einen SQL-Browser und verbindet sich direkt auf die DB.

Als sauberste Lösung bleibt hier eigentlich nur eine echte Server/Client-Anwendung und nur die Serversoftware hat Zugriff auf die DB.

Etwas aufwändiger, aber ohne Serversoftware: Du legst pro Mitarbeiter eine Tabelle "Entries_<userid>" an und gibst jedem Mitarbeiter nur auf diese Tabelle Schreibrechte, und auf alle anderen "Entries_*"-Tabellen gar keine Rechte. Erst der Controller darf auf alle Tabellen zugreifen und übernimmt dann am Ende des Monats die Werte in eine zentrale Tabelle "Entries".

Noch weniger aufwändig, aber gefuscht : Wenn Du im Client-Programm Username und Kennwort abfragst, vermurkst Du das Kennwort noch mit irgendeiner festen, zufälligen Kennung, bevor Du Dich an der DB anmeldest, also sowas wie
DB.Connect(user, 'DHz!64&'+pass+'vzFg'); Als Tabellen würd ich Dir vorschlagen:

• Mitarbeiter - Eine Liste aller Mitarbeiter
• Kunden - Eine Liste der Kunden
• Projekte - Die Liste der Projekte, die abgerechnet werden sollen. Kurzname, Beschreibung, Kunde, Letzte Abrechnung erfolgt am, Genehmigte Stunden, Bereits verrechnete Stunden, (StartZeitpunkt des Projekts, EndZeitpunkt, ...)
• Entries - MitarbeiterID, Datum, Startzeit, Endzeit, (Anzahl Minuten), Zuordnung zu Projekt, Abgerechnet Ja/Nein
• Rechnungen - Kunde, Projekt, ZeitraumStart, ZeitraumEnde, versandt Ja/Nein, Leistungsnachweis akzeptiert ja/nein, bezahlt ja/nein

Dann machst Du zwei Programme: ein etwas kleineres für die Mitarbeiter, die brauchen dann nur ReadOnly-Zugriff auf Kunden, Projekte und vollen Zugriff auf Entries_<userid>. Und dann ein programm für die Controller, die vollen Zugriff auf alles haben, und insbesondere die Tabellen "Entries_<userid>" anlegen und löschen können und mit den passenden Zugriffsrechten versehen können.

[DelphiManiac]

Danke mkinzler, Der_Unwissende:


Dass heißt,
ich erstelle eine Clientsoftware und eine Mastersoftware, die jeweils auf die Datenbank zugreifen.
Gut, also fange ich mal vorne an.

1x Firebird DB
1x Clientsoftware (für Zeiterfassungseingaben)
1x Mastersoftware für die Rechnungserstellung


Gibt es speziell für den Fall Delphi + Firebird entsprechende Tutorials?

Mit Delphi bin ich jetzt sol langsam warm geworden, deswegen wollte ich es auch gerne in Delphi realisieren.
Gut mit Datenbanken habe ich zurzeit nur mit Access (grässlich) und MySql im Zusammhang mit PHP gearbeitet.

Ist denn der Ansatz mit Client und Mastersoftware sinnvoll?

Gruß
DelphiManiac

[Der_Unwissende]

Zitat von DelphiManiac:

Gibt es speziell für den Fall Delphi + Firebird entsprechende Tutorials?

Ja, ja oder auch Firebird, also nochmal ja

Zitat von DelphiManiac:

Ist denn der Ansatz mit Client und Mastersoftware sinnvoll?

Auch hier gilt soweit erstmal ein klares ja. Die benötigen ja sicherlich eine ganz andere Sicht auf das Problem. Vorallem sollte man wohl aus der Mastersoftware heraus einen breiteren Zugriff haben. In dem Zusammenhang solltest Du Dich vielleicht ein wenig mit Views in Datenbanken auseinandersetzen.
Jedenfalls solltest Du trotzdem die beiden Programme nicht ganz isoliert betrachten. So sind bestimmte Klassen/Strukturen/Problemlösungen sicherlich für beide gleich wichtig. Hier wäre zum Beispiel die Anbindung an das DBMS zu nennen. Zwar greifen sie unterschiedlich darauf zu, trotzdem gibt es auch viele Gemeinsamkeiten. Mit einer eigenen Schicht zwischen den Programmen und dem DBMS kannst Du auch gleich dein Programm von einem speziellen DBMS entkoppeln (die Programme verwenden deine Abstraktionsschicht, zwischen welchem DBMS und der Anwendung die vermittelt bleibt transparent).

[mkinzler]

Man könnte aber durchaus alles in einem Programm machen, welches dann benutzerbezogen Funktionen freischaltet.

[DelphiManiac]

@mkinzler:

Ja das hast du Recht, werde es wohl auch in einem Programm abbilden.
Mit Zugriffsrechten/beschränkungen.

Ist eine Firebird Datenbank eine einzelne Datei, oder ist es wie bei MySQL aufgesplittet?

[mkinzler]

Zitat:

Ist eine Firebird Datenbank eine einzelne Datei, oder ist es wie bei MySQL aufgesplittet?

Ist eine Datei. (fdb)

[DelphiManiac]

@alle:

Nutzt jemand von euch das Admin Tool 'Marathon'?

Falls ja vielleicht könnt ihr mir ja erklären warum ich keine DB anlegen kann.
Ich gehe auf -->Create Database gebe alle wichtigen Informationen an. Und sage -->Create

Dann kommt folgender Fehler (Screenshot im Anhang),
dass Passwort und Benutzername fehlen, dies habe ich aber angegeben, trotzdem kann ich keine DB anlegen

Danke euch