Hallo,
ich wollte mal in die Runde fragen, was ihr so für Erfahrungen mit
verschiedenen Lösungsansätzen für Datenbank-Anwendungen gemacht habt?
Ich mache mir momentan Gedanken über eine Kunden-Verwaltung, in der
neben den Kundendaten auch die vertraglich mit den Kunden vereinbarten
Leistungen sowie die daraus resultierenden Zahlungsverpflichtungen
abgebildet werden sollen. Natürlich mit Rechnungserstellung(Drucker),
Mahnwesen und der Möglichkeit, frei formulierte Anschreiben an einzelne
Kunden zu verfassen. Der Kundenstamm weist prinzipbedingt eine gewisse
Fluktuation auf(alte Kunden gehen, neue Kunden kommen), bewegt sich aber
für den Zeitraum eines Jahres betrachtet vermutlich nicht mal im
vierstelligen Bereich.
Die Datenbank-Anwendung sollte nach Möglichkeit lokal auf einem
"normalen" PC laufen(momentan Win XP Home 32 Bit, in absehbarer Zeit
dann Win7 Home 64 Bit).
Da es in diesem Fal auch um die Abrechnung von Geldbeträgen geht, halte
ich eigentlich Transaktionen für Sinnvoll. Bislang habe ich Datenbanken
immer ohne Transaktionen programmiert und die von mir eingerichteten
Online-Shops(Virtuemart, diverse XTC-Forks, etc.) verwendeten meines
Wissens nach bei den DB-Zugriffen auch keine Transaktionen. Für
Transaktionen soll bei MySQL angeblich InnoDB notwendig sein. Kann mir
jemand sagen, ob Transaktionen in meinem Fall überhaupt sinnvoll sind?
Falls ja, könnte InnoDB sich bei einer Datenbank-Anwendung mit den von
mir beschriebenen Anforderungen in irgendeiner Hinsicht als
problematisch erweisen?
Dann gibt es da noch das Problem mit den Anwendern. Meiner Erfahrung
nach ist es verschwendete Zeit, den Anwender vollumfänglich im
verantwortungsvollen Umgang mit einem Eingabe-System zu schulen, um
Vorkehrungen wegen Fehleingaben oder Fehlbedienung überflüssig zu
machen. Bei Access empfand ich es immer als recht Mühsahm, das System
hinreichend vor dem Anwender zu schützen.
Womit habt ihr bei Datenbank-Anwendungen in dieser Beziehung gute
Erfahrungen gemacht?
Bei HTML/PHP/MySQL scheint man gefühlsmäßig gegen Windmühlen zu kämpfen,
da eine im Browser laufende Anwendung ja nun aus gutem Grund nicht über
die Möglichkeiten und Rechte verfügt wie eine selbst programmierte
Anwendung.
Wie flüssig und stabil läuft so eine Javascript/HTML/PHP/MySQL-Mixtur
dann in der Praxis?
Wie sieht es diesbezüglich mit Standard-Abläufen aus, wie z.B. ein auf
einer Vorlage basierendes Anschreiben, welches mit Kundendaten gefüllt
wird und wo ich dann vor dem Drucken noch eigenen Text formulieren kann?
Ich hätte vom programmiertechnischen Background theoretisch auch die
Möglichkeit, das ganze in C++ und entsprechendem Connector zu
programmieren. Da stellt sich mir die Frage, ob sich der Aufwand, das
alles selbst zu implementieren, überhaupt lohnt?
Hier würden mich auch mal praktische Vergleiche zu anderen
Programmiersprachen(z.B. .net) interessieren.
Grüße,
Fred
Fred schrieb:> Für Transaktionen soll bei MySQL angeblich InnoDB notwendig sein
So ist es. Auch für ForeignKeys wird die InnoDB benötigt, was aber auch
kein Nachteil ist.
Fred schrieb:> Da es in diesem Fal auch um die Abrechnung von Geldbeträgen geht,> halte ich eigentlich Transaktionen für Sinnvoll
Transaktionen sind immer sinnvoll im Zweifel ist einfach implizit
jeder SQL Befehl eine Transaktion, das merkt man nur nicht.
Man sollte sich aber bei deiner Anwendung nicht nur über die Transaktion
sondern insbesondere über das Isolationlevel Gedanken machen.
http://de.wikipedia.org/wiki/Isolation_%28Datenbank%29Fred schrieb:> Wie flüssig und stabil läuft so eine Javascript/HTML/PHP/MySQL-Mixtur> dann in der Praxis?
So stabil wie du es Programmierst, da die Daten eh zentral abgelegt
werden sind auch meist die eingeschränkten Rechte einer Webanwendung
eher uninteressant.
Fred schrieb:> Wie sieht es diesbezüglich mit Standard-Abläufen aus, wie z.B. ein auf> einer Vorlage basierendes Anschreiben, welches mit Kundendaten gefüllt> wird und wo ich dann vor dem Drucken noch eigenen Text formulieren kann?
Alles eine Frage des Workflows, wieso sollte das nicht möglich sein? Der
Server könnte z.B. ein vorausgefülltes Formular liefern, welches du nach
belieben füllst und zum Drucken daraus ein PDF generieren.
Fred schrieb:> theoretisch auch die Möglichkeit, das ganze in C++ und> entsprechendem Connector zu programmieren
Gehen tut das alles aber viel zu Aufwendig, wenn dann würde ich dir Java
(oder C# was dir mehr liegt) empfehlen.
>Dann gibt es da noch das Problem mit den Anwendern. Meiner Erfahrung
nach ist es verschwendete Zeit, den Anwender vollumfänglich im
verantwortungsvollen Umgang mit einem Eingabe-System zu schulen, um
Vorkehrungen wegen Fehleingaben oder Fehlbedienung überflüssig zu
machen. Bei Access empfand ich es immer als recht Mühsahm, das System
hinreichend vor dem Anwender zu schützen.
Es wird immer Fehleingaben geben. Die Frage ist dann nur wie einfach die
sich korrigieren lassen.
Hallo,
nur so als Hinweis: Wenn mit der Software Rechnungen erstellt werden
sollen, muss eine entsprechende Archivierung von Gesetzes wegen
sichergestellt sein - ich denke, als vermutlich Selbständiger kennst Du
Dich in diesem Bereich aber aus (bzw. kannst Dir die Informationen
beschaffen).
Eine bis zu vierstellige Kundenfluktuation pro Jahr klingt nach einem
etwas größeren Unternehmen - Frage: Besitzt Du keinen zentralen "Server"
(File-, Mailserver usw.) o. ä.? Unabhängig von dieser Lösung wäre eine
solche IT-Infrastruktur wohl ohnehin anzuraten, sobald zumindest eine
Person ihre Brötchen "in Vollzeit" damit verdient.
Transaktionen sind kein Hexenwerk, und browserbasierte Applikationen
(Stichwort: "Cloud") sind Stand der Technik; eine Desktopapplikation
würde ich heutzutage nur noch in Ausnahmefällen entwickeln. Speziell,
wenn ein zentraler Server zum Einsatz kommt, spielt eine
Browserapplikation ihre Vorteile aus.
Für Texteingabe o. ä. gibt es auch sehr gute JS-WYSIWYG-Editoren.
>pro Jahr klingt nach einem>etwas größeren Unternehmen
das kann man so nicht sagen, wenn du "displayschutzfolien" verkauft,
hast du 10000ende kunden
erzeugst du gasturbinen, hast du vielleicht nur 2
zum theman: eine fakturierung von 0 auf (samt mahnwesen)
naja, "mutig" würd ich mal sagen...
Fürs Geschäftliche muss man das Fahhrad nicht neu erfinden, da gibts
große und kleine Lösungen in OpenSurce mit Allem, was man braucht:
Artikelverwaltung, Kunden, Korrespondez, Rechnung, Mahnung ... bis hin
zu Workflow und BDE/PZE. Das Zauberwort "open crm" bzw. "open erp".
Z.B. hier, als fertig konfigurierte VM, die man per Browser anspricht,
incl. deutschem Handbuch:
http://www.seat-1.com/http://sourceforge.net/projects/intars/
Hallo allerseits,
erstmal danke für eure Antworten. Ein paar davon würde ich gerne
erörtern...
@Läubi
>Transaktionen sind immer sinnvoll im Zweifel ist einfach implizit>jeder SQL Befehl eine Transaktion, das merkt man nur nicht.
Klar, nur wie groß ist deren Bedeutung in dem von mir beschriebenen Fall
tatsächlich?
Ich spreche jetzt bewußt nicht von "jedem" SQL Befehl, sondern von
mehreren logisch zusammengehörenden nacheinander ablaufenden
SLQ-Statements, z.B. weil ich aufgrund des Datenbank-Designs beim
Anlegen eines Kunden dessen Daten in verschiedenen Tabellen vermerken
muss. Nun könnte ja theoretisch - aus welchen Gründen auch immer - eines
der SQL-Statements einen Fehler zurückgeben. In dem Fall wäre die
Transaktion bzw. das nun einsetzende Rollback dazu geeignet, einen aus
meiner Sicht inkonsistenten Datenbank-Zustand aufgrund der
vorhergehenden SQL-Statements zu vermeiden.
Nun will ich aber keine Datenbank von der Größe des
Reichelt-Online-Shops programmieren und viele andere Online-Shops
scheinen auch ohne die von mir dargestellten Transaktionen auszukommen.
In den meisten Access-Datenbanken, die ich so zu Gesicht bekommen habe,
hat auch so gut wie niemand Transaktionen in dem von mir angedachten
Sinn benutzt. Mich interessiert, wie Du bzw. ihr das Verhältnis von
Aufwand zu Nutzen bezogen auf den von mir skizzierten Einsatzzweck
beurteilt.
>Man sollte sich aber bei deiner Anwendung nicht nur über die Transaktion>sondern insbesondere über das Isolationlevel Gedanken machen.
Da stimme ich Dir grundsätzlich zu, aber ist das in meinem Fall wirklich
nötig?
Es handelt sich bei dem Unternehmen um eine kleine Yoga-Schule mit 3
kleinen Filialen, also kein größeres Unternehmen. In jeder Filiale steht
eine Office-Möhre mit Drucker, an dem eine Halbtagskraft die
Büro-Arbeiten verrichtet und auf dem dann später die Datenbank-Anwendung
lokal laufen soll. Es gibt also immer nur einen Datenbank-Benutzer, der
mit der jeweiligen lokalen Datenbank arbeitet.
>Alles eine Frage des Workflows, wieso sollte das nicht möglich sein? Der>Server könnte z.B. ein vorausgefülltes Formular liefern, welches du nach>belieben füllst und zum Drucken daraus ein PDF generieren.
Ich wollte mit meiner Frage nicht implizieren, dass dies generell nicht
möglich sei. Es geht mir eher um das notwendige Maß der "Vertrautheit",
das ein Anwender für gewöhnlich erwartet. Muss die in der Regel
weibliche Büro-Arbeitskraft mit eher geringen Informatik-Kenntnissen
dieses PDF erst "downloaden" und dann im Acrobat Reader öffnen und dann
von dort aus ausdrucken? Oder geht das auch nach dem übernächsten
Firefox- und AcrobatReader-Update genau wie früher unbemerkt im
Hintergrund, ohne dreizehn Klicks und vier verschiedene Fenster?
Das meinte ich mit Standard-Abläufen...
@Patrick
>nur so als Hinweis: Wenn mit der Software Rechnungen erstellt werden>sollen, muss eine entsprechende Archivierung von Gesetzes wegen>sichergestellt sein
Ist es nicht mehr erlaubt, die entsprechenden Daten auszudrucken und in
Papierform aufzubewahren? Das einfachste wäre doch immer noch, die
Rechnung oder was auch immer zusätzlich für die Archivierung
auszudrucken. Mit der geplanten Datenbank soll ja nicht gleichzeitig das
papierlose Büro Einzug in das Unternehmen erhalten, und elektronisch
gespeicherte Daten 10 Jahrte lang SICHER aufzubewahren, ist definitiv
eine Herausforderung.
>Speziell,>wenn ein zentraler Server zum Einsatz kommt, spielt eine>Browserapplikation ihre Vorteile aus.
Ich habe schon über einen Web-Server nachgedacht, auf den die Filialen
online zugreifen können. Webhosting ist heute ja dermaßen
preiswert...für 'nen 5er im Monat bekommt man bereits ausreichende
Pakete, um so etwas hochzuziehen. Aber was mich davor bisher
zurückschrecken lässt sind Themen wie Hacker-Angriffe und allgemeine
Internet-Störungen(verzögerte Arbeitsabläufe bis hin zum
Arbeitsausfall). Einen eigenen dedizierten Server mit VPN-Anbindung
kommt bei der Größe des Unternehmens nicht in Frage, es gibt ja nicht
mal eine Zentrale wo der stehen könnte, sondern lediglich die 3
Filialen. Mit "nicht mal im vierstelligen Bereich" wollte ich eher zum
Ausdruck bringen, dass es sich um ein kleines Unternehmen handelt.
>Für Texteingabe o. ä. gibt es auch sehr gute JS-WYSIWYG-Editoren.
Ja, das könnte so etwas wie MS Word in Bezug auf die
Datenbank-Anschreiben womöglich überflüssig machen...
@Robert L.
>zum theman: eine fakturierung von 0 auf (samt mahnwesen)>naja, "mutig" würd ich mal sagen...
Naja, das ist jetzt nicht meine erste Datenbank die ich programmiere und
mir ist genau aus diesem Grund schon klar, dass man so ein Projekt nicht
an einem Wochenende durchziehen kann, das werden wohl eher Monate
werden. Von daher würde es mich interessieren, wo genau Du da jetzt
größere Probleme siehst?
@Frank
>Fürs Geschäftliche muss man das Fahhrad nicht neu erfinden, da gibts>große und kleine Lösungen in OpenSurce mit Allem, was man braucht:
Keine schlechte Idee, allerdings müsste ein geeignetes Programm dann
schon unter Windows laufen...und dann ist die Frage, in wie weit diese
Programme für den von mir beschriebenen Einsatzzweck geeignet sind.
Wieviel Gehirnschmalz wird da wohl notwendig sein, um die Software an
das von mir beschriebenen Unternehmen(Yoga-Kurse, die an bestimmten
Tagen und zu bestimmten Uhrzeiten stattfinden) anzupassen?
Die Seat-1 Online Demo funktioniert bei mir leider nicht.
Grüße,
Fred
Fred schrieb:> Ich spreche jetzt bewußt nicht von "jedem" SQL Befehl, sondern von> mehreren logisch zusammengehörenden nacheinander ablaufenden> SLQ-Statements
Wie gesagt, man sollte immer wenn es geht explizit eine Transaktion für
so was starten.
Fred schrieb:> scheinen auch ohne die von mir dargestellten Transaktionen auszukommen
Ob das so sauber ist sei mal dahingestellt, das geht halt solange gut
bis mal was "knallt" und dann ist der Jammer groß.
Fred schrieb:> dieses PDF erst "downloaden" und dann im Acrobat Reader öffnen
Wenn dir Browser so konfiguriert ist, dass PDFs inline angezeigt werden
nicht..
> von dort aus ausdrucken?
Auf drucken muss man schon drücken (maximal kann man noch den
Druckdialog öffnen) du würdest ja nicht sehr froh sein, wenn beliebige
Webseites auf deinem lokalem Drucker Werbeflyer drucken oder? ;)
> Oder geht das auch nach dem übernächsten> Firefox- und AcrobatReader-Update genau wie früher
Meistens ja, auf jedenfall zuverlässiger als die meisten
Selbsstricklösungen welche dann natürlich genau mit diesem Drucker
Probleme haben.
> unbemerkt im Hintergrund
Man kann dafür natürlich das ganze mit JavaPaletts/Flash oder sonstigem
arbeiten stellt dan aber natürlich auch gewisse Anforderungen an den
Client.
Fred schrieb:> Einen eigenen dedizierten Server mit VPN-Anbindung> kommt bei der Größe des Unternehmens nicht in Frage
VPN und Telefonanalage in einem:
http://www.avm.de/de/Produkte/FRITZBox/FRITZ_Box_Fon_WLAN_7390/index.php
Aufbewahrungspflichten:
alles was "zur Aufklärung eines Geschäftsvorfalls" hilfreich oder
notwnedig ist, mß 10 Jahre aufbewahrt werden (auf Papier oder in der
EDV). zB eingehende PDF müssen momentan signiert ankommen, Du mußt
die Signatur überprüfen und den Kram aufheben (Schwachsinn, deshalb
mache das auch nur wenige. Die Signatur kostet auch ordentlich).
Da ist im Moment etwas im Busch, es soll geändert werden.
Datenbank:
Ist egal. mySQL etc sind ganz nett (ich verwende SQLite), die haben
aber alle ihre Grenzen in der Datenmenge. Leider update- und
pflegeintensiv.
Mittlerweile weiß auch jedes Skript-Kiddie wie man ein PHP hackt, es
ist nicht einfach, PHP richtig abzusichern.
Jedes DBMS hat heutzutage ein Transaktionssystem.
Auch Oracle legt bei 200 Mio Records die Ohren an, Kapazität checken.
Datensicherung:
min. täglich Pflicht. Denke an die Dateigrößen ... ein Monster von
100 GB Datenbankfile zwingt Dir alles in die Knie. Du mußt aber
sichern, es geht ums Geschäft.
Cloud:
Du bist ein netter Taliban und schiebst alles erst mal zu NSA/CIA
und FBI ? Das halte ich für bescheuert bis wahnsinnig.
Client:
Wenn Du das übers Web machst, dann ohne daß der Client etwas
installieren muß (Acrobat Reader und JavaScript kann man vorraussetzen).
Alles andere gibt irgendwann Ärger im Client. Rechne mit allen
Macken von IE6 bis IE8, FF und Opera (den Rest kann man ignorieren).
PDF:
Anzeige über eine iframe im Browser funktioniert bei allen IEs und FF.
PDF ist sehr praktisch, leider auch etwas komplex. Ein Riesenvorteil
von PDF ist, es kann so ziemlich alles an Grafikformaten anzeigen.
Scans vorher von zB TIFF nach PDF wandeln und dann erst ablegen.
Archiv:
Prinzipiell könntest Du bei Deinem Finanzamt fragen wie sie es haben
wollen. Sie wollen sich aber nicht festlegen: 1. darf man nicht
elektronisch archivieren (Gesetz aus den Nazizeit wo die Archivierung
auf Papier vorgeschrieben ist, es wurde nie aufgehoben) - 2: Laut
den neueren Gesetzen mußt Du elektronisch archivieren. Wie den
sprichtwörtlichen Pudding an die Wand nageln. Sie sagen: Ja das
müssen sie selbst wissen "bei der Prüfung entscheided der Prüfer".
Elektronisch archivieren ist erheblich kostengünstiger wie ein
Papierarchiv (keine Raumkosten, mehrere MA können auf den gleichen
Beleg zugreifen etc.). Kritisch sind nicht die Ausgangsrechnungen,
es sind die Eingangsrechnungen (wo Du Kosten bzw Vorsteuer geltend
machst). Da wird auch am meisten gemogelt.
Alle Ausgangsbelege kannst Du automatisch archivieren, Eingangsbelege
müssen sortiert, gescannt und verschlagwortet werden (Handarbeit).
Da gibt Barcodeaufkleber, OCR-Scanner die einem das Leben erleichtern.
---
In der Firma machen wir Archivierung als Dienstleister, Abfrage
über's Web. Datenmengen bis 600 GB Jahr Kunde.
Grüße Joe.
