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%29 Fred 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.