Hallo Leute, und zwar geht es um folgendes Problem: Ich muss ein Programm schreiben zur Auftragserfassung und Verwaltung. Grundsätzlich soll der Mitarbeiter eine paar Maske haben, wo er z.B. in der ersten Maske Auftragsnummer, Name, Datum, Maschine, Arbeitsstunden und Bemerkungen eintragen kann, aber keine Anderungen vornehmen kann. In der nächste Maske soll er zum Beispiel eintragen können wenn diverses Verbrauchsmaterial aus dem Lager entnommen wird. Dies soll von mehreren PC möglich sein. Des Weiteren sollte möglich sein, das bestimmte Personen diese Daten dann weiter verarbeiten können. Wie zum Beispiel nach einer Auftragsnummer suchen und den Auftrag automatisch nach kalkulieren (mit hinterlegten Stundensatz) kann und diese Kalkulation dann als PDF speicher können. Wie könnte man sowas am Besten an gehen? Grundsätzliche Programmiererfahrungen sind vorhanden, aber ich weiß halt nicht wo ich das umsetzen soll am besten. Excel VBA? Access? in Visual Studio? Vlt. kann mir jemand ein paar Tipps geben wie ich das angehen kann. LG FLorian
Dafür eignet sich ein relationales Datenbanksystem. MariaDB/MySQL wäre ein Beispiel. Die Ein- und Ausgabe könntest du dann mit Visual Studio programmieren aber auch mit php/html als Beispiel.
achso. visual studio erweckt auch den Anschein Datenbankfähigkeiten zu haben, kannste ja ausprobieren ich kann nur davon abraten.
danke für die rasche Antwort :) werde mich morgen mal damit auseinandersetzen und ein wenig einlesen! vielen dank :)
Florian K. schrieb: > Dies soll von mehreren PC möglich sein. Dann würde ich davon abraten das als Fat-Client zu implementieren. Implementiere das besser als Webapplikation mit Datenbankserver. Also z.B. die Webapplikation in Python mit Django und MariaDB als Datenbank. Django bietet alles nötige um einfach Formulare bereitzustellen und auf Datenbanken zuzugreifen. Die Nutzer können dann mit beliebigen Webbrowsern auf die Masken zugreifen. Das funktioniert dadurch unter Windows, Linux, MacOS, auf Smartphones etc.
Fuer so Kleinkram gibt es Oracleforms. Als Datenbank dazu Oracleexpress. Gegenueber irgendwelchem Webkram, ist man da in ueberschaubarer Zeit fertig.
Die Frage ist grundsätzlich, ob man das Fahrrad nun zum 500sten Mal neu erfinden muss. Ich bin sicher, dass es solche Systeme, z.B. auch als Modul/Plugin z.B. zu OpenERP oder in anderem Zusammenahng zuhauf bereits fertig gibt ...
Florian K. schrieb: > Vlt. kann mir jemand ein paar Tipps geben wie ich das angehen kann. Backend: relationale Datenbank. Frontend: scheissegal, was du halt am besten kannst (scheinbar rein garnix)
OpenERP heißt schon lange Odoo. Sobald man mehr als die wenigen Standard-Darstellungsformen braucht, wird es damit allerdings richtig kompliziert. Kann ich ehrlich nicht empfehlen.
Hier bei uns in der Firma schreibt jemand Jahrelang solche "Kleinigkeit" mit Access.
Wie Frank schon schreibt: warum neu machen? Bevor man sich an so eine Software macht, gibt es erstmal eine Marktanalyse, ob es nicht schon was passendes gibt. Wenn man nicht fündig wird, sind die Anforderungen in aller Regel schon sehr speziell. Da Du in einem Nebensatz zum Beispiel "Nachkalkulation" erwähnst, ist es mit Sicherheit keine reines Erfassen und Ablegen von Aufträgen mit Recherge-Funktion. Dann macht man das aber auch nicht mal eben nebenbei. Für so eine Umsetzung gibt es zig verschiedene Ansätze, die alle ihre Vor- und Nachteile haben (Web, Fat-Client, Thin-Client, Multi-Tier, monolitisch um nur einige Bullshit-Bingo-Begriffe zu nennen). Dabei ist nur die grundlegende Architektur gemeint ohne Auwahl einer spezifischen Datenbank (die alle auch wieder ihre Vor- und Nachteile haben) oder der Programmiersprache / -umgebung (für die natürlich wieder das gleiche gilt). Ohne eine gewisse Erfahrung in dem Bereich ist das Scheitern deshalb meist vorprogrammiert. Ich baue haupberuflich seit mehr als 20 Jahren Datenbank-Anwendung und habe schon jede Menge Mist gesehen, der daraus resultiert, dass man "mal eben schnell" etwas machen wollte. Deshalb mein erstnst gemeinter Rat: lass es! Such Dir eine fertige Anwenung oder jemand mit Erfahrung, der das für Euch baut.
Larry schrieb: > Fuer so Kleinkram gibt es Oracleforms. > Als Datenbank dazu Oracleexpress. Tany schrieb: > Hier bei uns in der Firma schreibt jemand Jahrelang solche "Kleinigkeit" > mit Access. Gibt es noch mehr wahnsinnige Vorschläge? Florian K. schrieb: > Wie könnte man sowas am Besten an gehen? Grundsätzliche > Programmiererfahrungen sind vorhanden, aber ich weiß halt nicht wo ich > das umsetzen soll am besten. Excel VBA? Access? in Visual Studio? Bei deinen Programmvorschlägen sind ganz klar keine Programmiererfahrungen vorhanden. Such dir was fertiges, denn alles andere wird nur Mist.
Florian K. schrieb: > Ich muss ein Programm schreiben zur Auftragserfassung und Verwaltung. Ein ERP System von Grund auf? Herzlichen Glückwunsch! > Grundsätzlich soll der Mitarbeiter eine paar Maske haben, wo er z.B. in > der ersten Maske Auftragsnummer, Name, Datum, Maschine, Arbeitsstunden > und Bemerkungen eintragen kann, Kann dein ERP System das nicht? Was habt ihr denn? > Des Weiteren sollte möglich sein, das bestimmte Personen diese Daten > dann weiter verarbeiten können. Was ja der Sinn ist. > Wie zum Beispiel nach einer > Auftragsnummer suchen und den Auftrag automatisch nach kalkulieren (mit > hinterlegten Stundensatz) kann und diese Kalkulation dann als PDF > speicher können. Wie wäre es mit "als Angebot versenden" und "in Rechnung stellen"? immer dran denken: Wenn die Rechnung nicht bezahlt ist, verdient die Firma kein Geld und hat keine Daseinsberechtigung. > Wie könnte man sowas am Besten an gehen? So wie deine ERP das will. Zur not mit einer webapplikation die das an das ERP weiterreicht.
ich für meinen Teil mag MySQL.. aber ich bin auch alt ;) Wenn man sowas mal 'kurz zusammenprutschen' will wie wir im Pott so sagen, dann empfehl ich Dir mal einen kurzen Blick auf Ultimatepp zu werfen, (ultimatepp.org) Nicht die schönste Lösung, aber kost nix, liefert aber alles was man braucht direkt mit (C++ bis an die Zähne überbewaffnet mit Zeug) Ich hab damit was sehr ähnliches (Ablauf nicht Inhalt -Echtzeit Lagerbestand direkt dem Verkauf anzeigen incl Aussendienstlern) innerhalb von nem Tag zusammengerotzt. zwei drei Eingabemasken für die Lageristen, zwei drei für den Verkauf, ne online stehende mysql mit definierten lese-schreibrechten etc.. (und dann im Laufe der nächsten Tage ordentlich gemacht natürlich.. blieb sogar ein ultimatepp Projekt) Ist immernochnicht mein Lieblings-Tool um ehrlich zu sein.. bleibt aber C++ und dank der netten Grafikgimmicks (Tabellen sortierbar filterbar, etc.. ohne mein zutun) für die GUI ging's eben schneller so :D prinzipiell reicht aber mysqlcppconn um selbst in visual studio und Kommandozeile and die Datenbank zu kommen.. MSsql (das was visual studio selbst gerne hätte das man es benutzt...) naja.. nicht meins sagen wir mal 'sid
sid schrieb: > ich für meinen Teil mag MySQL.. > aber ich bin auch alt ;) Merkt man. MySQL heißt seit ein paar Jahren MariaDB. Den Namen MySQL nutzt Oracle für einen Fork des Projektes (kann man auch genau umgekehrt sehen). Bisher hat Oracle alle mir bekannten Open-Source Projekte nach der Übernahme gegen die Wand gefahren. Daher mein Tipp: Wenn du das alte MySQL 5 magst, dann wechsle zu MariaDB.
Stefanus F. schrieb: > Merkt man. MySQL heißt seit ein paar Jahren MariaDB. hehe, ich mag die Idee hinter Maria DB und der Herr Widenius hat meinen höchsten Respekt natürlich.. dennoch als ich vor fast zehn Jahren mal was portieren wollte, gab es einen derartigen Haufen Probleme dass ich sie nichtmal hier auflisten könnte wenn ich mich vollständig erinnerte, ich hab prinzipiell ne Woche lang Patches gesucht nur um dann einen Performance gain von weniger als 0.1% zu erzielen... mit dem Endresultat dass die Datenbank nach ein paar weiteren Wochen crashte, aus mir damals unerfindlichen Gründen (vermutlich ein buggy patch irgendwo) Seitdem greift bei mir irgendwie die "gebranntes Kind" Regel.. obwohl ich sicher bin, dass jetzt alles stabiler ist als noch 2009/2010 kleb ich trotz Oracle weiterhin an MySQL, da weiss ich wenigstens dass jeder auftretende Fehler meine Schuld ist; bei Maria hätte ich immer den Verdacht es gäb doch wieder irgendein Problem mit der Implementierung.. oder kurz.. ich schieb den nächsten mariaDB test vor mir her bis ich dann in Rente gehe vermutlich LOL Und ich wiederspreche.. MySQL heisst MySQl (immernoch wie schon anno Dunst) und MariaDB heisst eben MariaDB (obschon beides von Widenius und Co) Opera bleibt auch Opera und Vivaldi ist eben ein 'anderer Browser'... 'sid
Ich habe mit MariaDB gewerblich gute Erfahrung gemacht. "Unsere" Firma entwickelt und betreibt Software als Service. Wir haben ungefähr 15 Anwendungen nach und nach von MySQL 5 nach MariaDB 10 aktualisiert und sind dabei nur auf eine einzige kleine Inkompatibilität gestoßen. Eine SQL Prozedur musste angepasst werden, das war's schon. Es stellte sich heraus, dass wir sie bei einem Upgrade von MySQL nach MySQL (neuer Version) ebenso hätten anpassen müssen. Bei MySQL und MariaDB gibt es zwei Dinge, die mich nerven: a) Unterstützt verschachtelten Transaktionen nicht richtig, was bei Java EE Anwendungen zwar kein Show-Stopper aber immerhin ein Hindernis ist. b) Verweigert sporadisch einzelne gültige Zugriffe (Fehler 1205 Lock Timeout), vor allem wenn die Systemlast hoch ist. Die Entwickler der DB verschieben hier die Verantwortung einfach auf den Anwendungsentwickler - soll er halt wiederholen. In der Praxis ist das allerdings keineswegs so einfach wie es klingt. In einer Web basierten Abwendung führt dies praktisch immer zu einem Folgefehler: Timeout in irgendeiner M2M Kommunikation. Ich hasse dieses Manko wie die Pest. Ansonsten: Dem geschenkten Gaul schaut man nicht ins Maul oder so. Wenn man weiß, worauf man sich einlässt, kommt man irgendwie klar. Ist immer noch besser als selber neu-erfinden oder die hohen Kosten einer Oracle Lizenz.
Stefanus F. schrieb: > b) Verweigert sporadisch einzelne gültige Zugriffe (Fehler 1205 Lock > Timeout), vor allem wenn die Systemlast hoch ist. Die Entwickler der DB > verschieben hier die Verantwortung einfach auf den Anwendungsentwickler > - soll er halt wiederholen. In der Praxis ist das allerdings keineswegs > so einfach wie es klingt. In einer Web basierten Abwendung führt dies > praktisch immer zu einem Folgefehler: Timeout in irgendeiner M2M > Kommunikation. > Ich hasse dieses Manko wie die Pest. Gibt's dazu einen Bugreport? Grundsätzlich hört sich das ja nach normalem Verhalten eines transaktionalen RDBMS an. Einerseits hätte ich hier auch einmal die Anwendung im Verdacht, andererseits muss man leider mit zurückgerollten/abgebrochenen umgehen können, wenn man kein Schneckentempo möchte. Ich würde mir in so einem Fall mal die aktuelle Sperrsituation ansehen, wahrscheinlich verhakt sich da anwendungsseitig etwas.
Jan H. schrieb: > Gibt's dazu einen Bugreport? Gefühlt hunderte - seit mehr als 10 Jahren immer wieder neue. ich habe inzwischen in der dritten Firma Probleme damit. Alles sehr unterschiedliche Projekte die alle nicht von mir kommen. Insofern kann ich ausschließen, dass ich es selbst verbockt habe :-) Man kann den Fehler gezielt mit einem select-join auslösen (also reiner Lesezugriff mit nur einem einzigen aktiven user). Ich habe dieses erschreckende SQL Statement leider nicht auswendig im Kopf. > wahrscheinlich verhakt sich da anwendungsseitig etwas. Ja, ist auch so, die DB verhakt sich selbst. Das hat irgendwie mit der Blockweisen Verarbeitung von Indexen zu tun.
Sebastian L. schrieb: > Florian K. schrieb: >> Ich muss ein Programm schreiben zur Auftragserfassung und Verwaltung. > Ein ERP System von Grund auf? > Herzlichen Glückwunsch! > >> Grundsätzlich soll der Mitarbeiter eine paar Maske haben, wo er z.B. in >> der ersten Maske Auftragsnummer, Name, Datum, Maschine, Arbeitsstunden >> und Bemerkungen eintragen kann, > Kann dein ERP System das nicht? Was habt ihr denn? > >> Des Weiteren sollte möglich sein, das bestimmte Personen diese Daten >> dann weiter verarbeiten können. > Was ja der Sinn ist. >> Wie könnte man sowas am Besten an gehen? > So wie deine ERP das will. Zur not mit einer webapplikation die das an > das ERP weiterreicht. Das zeigt wieder mal das Du keinerlei Ahnung hast. Du weisst weder was ein ERP System überhaupt ist, noch das die Frage nichts mit einem ERP System zu tun hat.
Stefanus F. schrieb: > Ansonsten: Dem geschenkten Gaul schaut man nicht ins Maul oder so. Wenn > man weiß, worauf man sich einlässt, kommt man irgendwie klar. Ist immer > noch besser als selber neu-erfinden oder die hohen Kosten einer Oracle > Lizenz. Ich weiß nicht, wo dein Problem ist. PostgreSQL ist genauso für Umme wie MySQL, aber dafür seit Jahren vollkommen ausgewachsen und sehr stabil. So stabil dass die Entwickler in letzter Zeit (wohl vor lauter Langeweile) einen Haufen Features einbauen, die man eigentlich garnicht braucht. Naja, und ein paar, die wirklich nützlich sind auch... MySQL ist im Verhältnis zu PostgreSQL ungefähr Trabi von 1968 im Vergleich zu einem heutigen VW Golf. Ja klar, auch mit dem Trabi konnte man fahren. Irgendwie...
c-hater schrieb: > Ich weiß nicht, wo dein Problem ist. PostgreSQL ist genauso für Umme wie > MySQL, aber dafür seit Jahren vollkommen ausgewachsen und sehr stabil. Mein Problem ist, dass ich per Order Mufti schon mein ganzes Leben lang immer MySQL/MariaDB benutzen musste (in 4 Firmen). PostgreSQL habe ich 2 Monate lang evaluiert, bis das Management entschied, dass ich doch bei MySQL/MariaDB bleiben muss. Diese Locking Probleme hatte ich mit PostgreSQL nicht, aber das heißt nicht viel, denn in der Entwicklung-Test Umgebung habe ich mit MySQL/MariaDB auch nie Probleme. Die treten immer nur in der Produktion auf, wenn gerade keiner da ist. Aber schön zu lesen, dass auch du PostgreSQL empfiehlst.
Stefanus F. schrieb: > Diese Locking Probleme hatte ich mit PostgreSQL nicht, aber das heißt > nicht viel Je nachdem, was du unter "Lockingproblemen" verstehst... Natürlich gibt es in JEDER transaktionsfähigen DB die Möglichkeit für Deadlocks. Somit natürlich auch in PostgreSQL. Und es ist tatsächlich immer der Job des Programmierers, diese Probleme zu vermeiden oder zumindest zu minimieren, auch in PostgreSQL oder Oracle. Das prinzipielle Problem ist: es gibt halt Aufgabenstellungen (leider sind das in der Praxis garnicht so wenige), die ausschließen, dass man einen Deadlock sicher vermeiden kann. Er wird dann also (spätestens bei hinreichend Last) irgendwann ganz sicher auftreten. Es ist dann auch wieder Sache des Programmierers, diese Situation sinnvoll aufzulösen. Was natürlich letztlich immer nur dadurch passieren kann, dass das Deadlock-Opfer seine Transaktion zurückrollt und erneut ausführt. Dabei allerdings kommt dann wieder voll die DB und ihre Fähigkeiten in's Spiel. Insbesondere die vollständige Unterstützung von nested transactions seitens der DB ist überaus hilfreich für den Programmierer. Naja, jedenfalls für den, der weiss, was er da eigentlich tut...
c-hater schrieb: > Insbesondere die vollständige Unterstützung von nested > transactions seitens der DB ist überaus hilfreich für den Programmierer. Das denke ich auch. Leider ist MySQL/MariaDB gerade hier eingeschränkt.
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.