WaWi in AutoIt - Projekt für AutoIt / SQLite zu groß?

  • Hallo zusammen,

    ich habe vll. bald die Aufgabe ein kleines "Warenwirtschaftssystem" zu programmieren. Zunächst nur Artikel-Liste, Kunden-Daten, Kasse. Was geklärt werden muss:
    - AutoIt gut genug um die Datenmengen zu verarbeiten?
    - SQLite gut genug um die Datenmengen zu verarbeiten?
    Alternativen:
    - AutoIt und MySQL?
    - C# und MySQL/Oracle? Muss mich hier nochmal erkundigen, ich meine es gab eine etwas eingeschränke Version kostenfrei und legal vom Visual Studio.
    - Fertiges Produkt kaufen

    Dabei ist zusagen, dass voraussichtlich das Programm so ausschaut, das es 3 oder 4 verschiedene Masken gibt, die jeweils Listviews nutzen. Alle Daten werden/müssen in der Datenbank gespeichert (werden). Artikelstamm wird wahrscheinlich um die 10.000 Artikel werden.

    Hat jemand Erfahrungen oder Ratschläge für mich, ob das zu groß wird um es mit AutoIt zu lösen? Die GUIs etc. müssen nicht alle binnen 2 Sekunden reagieren, aber wenn ich mal mit meinem Skript ein weng rumspiele wird es ab 10.000 schon hart :D

    Alternativ kaufbare WaWi Systeme?

    Hoffe ihr habt ein paar Tpps für mich.


    Grüße Yaerox

    Grüne Hölle

  • Das kann ich heute Nachmittag gerne mal ausprobieren. Bin jetzt bis 16 Uhr erstmal unterwegs. Nur mit dem Tool muss halt auch wirklich ein ganzen Tag gearbeitet werden. Ich muss da auch nochmal ein paar Tests machen zur Speicherfreigabe. In einem alten Projekt von mir gab es da Probleme, weil bei meiner Listview der Speicher nach dem löschen der Inhalte nicht 100%ig freigegeben worden war. Daher musste ich auf ListBoxen umsteigen. Das wäre hier aber nicht so toll ^^

    Grüße Yaerox

    Grüne Hölle

  • Alle Daten werden/müssen in der Datenbank gespeichert (werden). Artikelstamm wird wahrscheinlich um die 10.000 Artikel werden.

    Und der Artikelstamm wird nur lokal verwendet?
    Sollte es nicht eher eine zentrale DB für mehrere Clients geben?
    Ich habe keine Ahnung von Warenwirtschaftssystemen aber spontan hätte ich ein serverbasiertes DBMS bevorzugt (MariaDB oder PostgreSQL oder was kommerzielles wenn die Lizenzen da sind) gegenüber SQLite.
    Die kannst du auch alle über AutoIt ansprechen (z.B. über ADODB)

  • Ich habe erst vor kurzem ein kleines Warenwirtschaftssystem in AutoIt geschrieben, allerdings eher als Testprojekt. Das Ganze baut auf nativem AutoIt und einer MySQL-Datenbank auf, ist also Multiclient-Fähig. Die Artikel werden erfahrungsgemäß ja nicht über das ListView direkt ausgewählt, sondern über eine Suchmaske. Dann ist die Darstellung auch kein Problem. Du musst bei einem so großen Projekt nur darauf achten, einem Programmier- und Strukturschema zu folgen. Sonst wird's schief gehen. Ich habe zum Beispiel jedes View, also jede GUI, in eine Unterdatei ausgelagert. So kann man ohne viel Suchen schnell Änderungen vornehmen. Auch die Ausgabe einer Rechnung als PDF ist ohne weiteres aus AutoIt heraus möglich. Die Welt der UDFs steht dir offen.

  • Und der Artikelstamm wird nur lokal verwendet?Sollte es nicht eher eine zentrale DB für mehrere Clients geben?
    Ich habe keine Ahnung von Warenwirtschaftssystemen aber spontan hätte ich ein serverbasiertes DBMS bevorzugt (MariaDB oder PostgreSQL oder was kommerzielles wenn die Lizenzen da sind) gegenüber SQLite.
    Die kannst du auch alle über AutoIt ansprechen (z.B. über ADODB)

    Der Artikelstamm wird nur lokal verwendet. Mehrere Clients wird es vorerst nicht geben. Später vll. Guter Punkt, daher wäre die Wahl zur MySQL DB vll. nicht schlecht.

    Ich habe erst vor kurzem ein kleines Warenwirtschaftssystem in AutoIt geschrieben, allerdings eher als Testprojekt. Das Ganze baut auf nativem AutoIt und einer MySQL-Datenbank auf, ist also Multiclient-Fähig. Die Artikel werden erfahrungsgemäß ja nicht über das ListView direkt ausgewählt, sondern über eine Suchmaske. Dann ist die Darstellung auch kein Problem. Du musst bei einem so großen Projekt nur darauf achten, einem Programmier- und Strukturschema zu folgen. Sonst wird's schief gehen. Ich habe zum Beispiel jedes View, also jede GUI, in eine Unterdatei ausgelagert. So kann man ohne viel Suchen schnell Änderungen vornehmen. Auch die Ausgabe einer Rechnung als PDF ist ohne weiteres aus AutoIt heraus möglich. Die Welt der UDFs steht dir offen.

    Das Wawi soll für meinem Bruder sein. Der wird sich in naher Zukunft selbstständig machen. Daher ist leider keine Zeit das Wawi als "Testprojekt" zu entwickeln und zu schauen. Daher muss ich vorher jetzt gut überlegen, ob das was werden kann, oder nicht. Ein Struktur- und Programmierschema wird beibehalten, Neuentwicklung und vorherige Planung sind mir ausreichend bekannt. Mir ist halt wichtig, dass das Projekt auch längerfristg taugt. Kannst du mir vll. noch ein paar weitere Informationen/Einschätzungen geben, z.B.:

    - Ist AutoIt in Verbindung mit MySQL prinzipiell langsamer, als z.B. mit einer SQLite DB, oder gibt es da keine/wenige Unterschiede? Für mich z.B. scheint es so, als ob SQLite die DB ist, die AutoIt am nähsten steht. Ist das nicht so? Ich lasse mich gerne von anderen ERfahrungen überzeugen. Ich habe mit AutoIt noch nie in Verbindung mit einer anderen DB als SQLite gearbeitet.
    - Denkst du, dass prinzipiel auch ein Multi-Client-User betrieb einwandfrei funktionieren wird, oder hat AutoIt dir da bekannte Schwachstellen?

    Es gibt auch noch ein paar andere Dinge, die ich noch nie mit AutoIt gemacht habe, z.B. PDFs erstellen, was ein wichtiger Punkt wird. Hast du da vll. die Möglichkeit mir ggf. einige kleine Beispiele zu zeigen, bzw. weißt du, ob ich eine PDF erzeugen kann, aus einer Word-Vorlage (Rechnung mit Rechnungskopf, Logo etc.)?

    Grüße Yaerox

    Grüne Hölle

  • Hallo!

    Deine Anforderung sollte für AutoIT kein Problem sein. Ich habe für meine Freundin die Selbstständig ist eine komplettes Kassenbuch inkl. Ausgabe für die Steuerprüfung (als PDF) geschrieben - in zwei Wochen!

    Meine Erfahrung ist das es nicht immer gleich eine Datenbank sein muss, sondern auch mal ein lokales File reicht. Selbst bei grösseren Datenmengen ist das kein Problem. 20000 Einträge kann ich in ca. 1 bis 2 Sekunden (auf einen kleinen i3) durchsuchen. Sollte für den Anfang reichen. Durch geschickte Programmierung kann man sicher auch noch rausholen (Querverweise).

    Die Ausgabe über PDF war ein bißchen "zickig" da in der UDF einige Fehler sind. Diese habe ich ausgebessert und jetzt funkt es echt super!

    lg
    Racer

    PS: ganz wichtig: Das Forum hat mir bei einigen Fragen zu meine Projekt sehr weitergeholfen: Danke nochmals an alle!

    • Offizieller Beitrag

    Grundsätzlich stellt es kein Problem dar SQLite zu verwenden. Wobei man aus Komfortgründen auch eine Datenbank verwenden könnte, die den Datentyp "DATUM" verwendet. In SQLite musst du das über eigene Konvertierungsfunktionen managen (sei es Datum als Integer oder String).
    Ansonsten wird SQLite den Anforderungen voll gerecht (Trigger, Generatoren - alles vorhanden).

  • SQLite ist halt nur nicht von Haus aus für Multiclient-Zugriff geeignet. Ich weiß gar nicht, ob das überhaupt geht, aber selbst wenn, würde die SQLite-Datei auf einem Server liegen müssen, mit einer Dateifreigabe usw... Ist imho nicht optimal. Bei MySQL läuft alles über einen Datenbankserver, sodass man sich das Gefuddel mit den Dateien direkt sparen kann. Und ob dann eine oder zehn Verbindungen zur Datenbank aufgebaut werden, ist komplett egal. Du kannst das praktisch ohne Umbau oder spezielle Programmierung für Multiclient-Zugriff nutzen. Musst ggf. nur eine intervallartige DB-Abfrage basteln. Daher ist in meinen Augen MySQL besser geeignet. Auch die Option mit den einzelnen Dateien halte ich eher für eine Notlösung. Datenbanken sind einfach leichter zu handhaben. Du kannst die fertigen Funktionen mit SQL nutzen und obendrein erfindest du nicht noch ein unnötiges, proprietäres Datenformat. Was die andere konkrete Frage angeht... Nein, ich habe noch keine Schwächen seitens AutoIt im Multiclient-Betrieb festgestellt. Hängt alles vom Programmierer ab. Wenn du geschickt bist, läuft das einwandfrei.

  • SQLite ist halt nur nicht von Haus aus für Multiclient-Zugriff geeignet. Ich weiß gar nicht, ob das überhaupt geht, aber selbst wenn, würde die SQLite-Datei auf einem Server liegen müssen, mit einer Dateifreigabe usw... Ist imho nicht optimal. Bei MySQL läuft alles über einen Datenbankserver, sodass man sich das Gefuddel mit den Dateien direkt sparen kann. Und ob dann eine oder zehn Verbindungen zur Datenbank aufgebaut werden, ist komplett egal. Du kannst das praktisch ohne Umbau oder spezielle Programmierung für Multiclient-Zugriff nutzen. Musst ggf. nur eine intervallartige DB-Abfrage basteln. Daher ist in meinen Augen MySQL besser geeignet. Auch die Option mit den einzelnen Dateien halte ich eher für eine Notlösung. Datenbanken sind einfach leichter zu handhaben. Du kannst die fertigen Funktionen mit SQL nutzen und obendrein erfindest du nicht noch ein unnötiges, proprietäres Datenformat. Was die andere konkrete Frage angeht... Nein, ich habe noch keine Schwächen seitens AutoIt im Multiclient-Betrieb festgestellt. Hängt alles vom Programmierer ab. Wenn du geschickt bist, läuft das einwandfrei.

    Ich hab es vll. bisher nicht direkt erwähnt, aber vorerst wird es nur einen PC geben. Im Unternehmen stehen zwar 2 Rechner, aber der zweite ist nur im Falle eines Ausfalles zur Nutzung gedacht. Sprich, die DB wird egal ob SQLite oder MySQL lokal auf dem Rechner laufen. Es wird jedoch mit Hilfe von Festplatten/NAS Systeme eine Datensicherung geben. Die Punkte dir mir momentan am meisten in den Gedanken vorschweben ist:

    - Multi-User in Zukunft (einer Inventarisiert Ware, der andere verkauft). Es muss quasi alle zwei Stunden Ware inventarisiert werden. Nebenbei müssen aber dennoch die Verkäufe weitergeführt werden. Sprich es sollte wahrscheinlich direkt auf Multi-User Fähigkeit geachtet werden. Das hat sich jetzt erst so langsam aber sicher herauskristalisiert.

    @chesstiger aber du siehst keinerlei Einschränkungen, wenn ich AutoIt mit MySQL nutze?

    Grüße Yaerox

    Grüne Hölle

    • Offizieller Beitrag

    Für deine Form der Multiusernutzung kannst du problemlos auch SQLite nutzen. Die DB wird während eines Zugriffs (der in der Regel nur einige ms dauert) gesperrt. Hier kann mann durch das Absetzen der Queries über einen Puffer dafür sorgen, dass diese nicht ins Leere laufen. Wenn Query mit Fehler endet: 10 ms warten (oder auch 100, für den User unerheblich) und erneut durchführen, dann sollte die DB wieder frei sein. Wenn wieder Fehler nochmal das ganze bis zu einer $MAX -Zahl an Zugriffen, nach der du davon ausgehen musst, dass ein generelles Zugriffsproblem besteht.

  • Diese ganze Fehlerüberprüfung und Pufferei kann man sich allerdings sparen, wenn man direkt MySQL verwendet. Noch dazu spart man sich dann die Dateifreigaben. Warum soll man sich eine Single-Session-Lösung zurechtbiegen, wenn man auch gleich die Multi-Session-Lösung verwenden kann?

    In meinen Augen gibt es bei der Kombination MySQL u. AutoIt keinerlei Einschränkungen. Solange du mit SQL umgehen kannst, macht die Handhabung von MySQL und SQLite kaum einen Unterschied.

  • Für deine Form der Multiusernutzung kannst du problemlos auch SQLite nutzen. Die DB wird während eines Zugriffs (der in der Regel nur einige ms dauert) gesperrt. Hier kann mann durch das Absetzen der Queries über einen Puffer dafür sorgen, dass diese nicht ins Leere laufen. Wenn Query mit Fehler endet: 10 ms warten (oder auch 100, für den User unerheblich) und erneut durchführen, dann sollte die DB wieder frei sein. Wenn wieder Fehler nochmal das ganze bis zu einer $MAX -Zahl an Zugriffen, nach der du davon ausgehen musst, dass ein generelles Zugriffsproblem besteht.

    Diese ganze Fehlerüberprüfung und Pufferei kann man sich allerdings sparen, wenn man direkt MySQL verwendet. Noch dazu spart man sich dann die Dateifreigaben. Warum soll man sich eine Single-Session-Lösung zurechtbiegen, wenn man auch gleich die Multi-Session-Lösung verwenden kann?

    In meinen Augen gibt es bei der Kombination MySQL u. AutoIt keinerlei Einschränkungen. Solange du mit SQL umgehen kannst, macht die Handhabung von MySQL und SQLite kaum einen Unterschied.

    Danke euch beiden für die vielen Ratschläge. Ich muss mich da am Wochenende mal hinsetzen und überlegen, was und wie ich das nun löse. Im Raum stehen immer noch einige fertige Lösungen. Da das ganze nicht für mich ist, werde ich nochmal einige Listen an Vor-/Nachteilen versuchen aufzustellen und dann langsam eine Entscheidung treffen müssen.

    Grüße Yaerox

    Grüne Hölle