Welche Programmiersprache

Spricht ja eigentlich e nix gegen PHP&MySQL, oder?
lediglich für den barcode reader wirst du wahrscheinlich einen client brauchen... ob dies mit java realisierbar ist kann ich nicht sagen, täte aber hier C o.ä. verwenden
ich weis nicht genau wie die barcodereader hinsichtlich der software funktionieren, aber kann es mir wie oben beschrieben vorstellen

Thomas

denke auch, dass die kombination von PHP&MySQL sowie C für den barcodeleser am einfachsten ist. musst hald ne schnittstelle definieren (dafür reicht im prinzip ne primitive textdatei.. aber hald primitiv!^^)

die 0815 barcodescanner brauchen keinen speziellen client.
die emulieren einfach eine tastatur und geben beim scan die entsprechenden keystrokes mit.
habe schon einige php/mysql applikationen mit barcodescannern programmiert. funkt perfekt

Zitat von spotnik

Hallo!
Das mit dem Barcodeleser ist kein Problem.
Naja, was gegen PHP spricht ist, dass ich damit keine Rechnungen automatisch drucken kann. Ich könnte mir mit PHP nur eine pdf-Datei erstelle lassen und die müsste ich dann "händisch" ausdrucken. Viel zu umständlich! Der Druckvorgang sollte im Hintergrund ablaufen, ohne das ich je die Seite am Bildschirm angezeigt bekomme. Ich hoffe ihr versteht was ich meine!?

Manuel

auch das habe ich erfolgreich realisiert. Die PDFs werden auf einem Netzwerkshare abgelegt, auf den PCs (Windows) läuft ein kleines WSH-Script das die Shares überwacht und bei Bedarf automatisch ausdruckt.

C für so einen Client? Da würde ich eher zu Java greifen, macht keinen Sinn, sich dafür C anzutun. Oder meinetwegen Python, Ruby, irgendein komisches .NET Zeug oder sonstwas...
Zu PHP sag ich nichts...

Zitat von DomiN

auch das habe ich erfolgreich realisiert. Die PDFs werden auf einem Netzwerkshare abgelegt, auf den PCs (Windows) läuft ein kleines WSH-Script das die Shares überwacht und bei Bedarf automatisch ausdruckt.

Meiner Erfahrung nach führen Bastellösungen immer zu Chaos früher oder später.

Ich würde ein Java SWT-App empfehlen zu bauen, wenn Java-Kenntnisse schon da sind. Backend einfach direkt mit MySQL via Netzwerk, oder wenns was aufwändigeres sein muss (zB irgendwelche autonomen Berechnungen machen), dann mit PHP&MySQL.

Größere Dinge (und so ein Ding *ist* was größeres) sollte man nie mit komplett neuen Tools anfangen, da verhaut man sich zu viel wenn man falsch anfängt.

.NET mit C#, WCF und PostgreSQL :ausheck:
Klingt nach Smart Client - WPF (Composite Library). PHP würde ich net machen in diesem speziellen Fall ...

Zitat von hal

Meiner Erfahrung nach führen Bastellösungen immer zu Chaos früher oder später.

Individualsoftware ist imho generell eine Bastellösung.
Ich muss zugeben, das WSH-Skript ist aus anderen Belangen gekommen. Es gibt einen Drucker, auf dem bestimmte Dokumente ausgedruckt werden sollen. Diese werden ausgelöst, sobald bestimmte Rahmenbedinungen erfüllt sind...blabla. Aber, Chaos war vorher, jetzt nimma

MySQL, PostgreSQL, OracleSunWTF, M$SQL ist so belanglos zu fragen. Fragst 10 Leute kriegst 12 Meinungen. Mein Tipp: ist PostgreSQL

Zu: Java, PHP, C, .NET(#~*), Brainfuck, lolcode,... : Nimm die mit der du am vertrautesten bist oder du es dir leisten kannst/willst dich darin einzuarbeiten.
Ich bin grundsätzlich ein Freund von Systemen, die dem Client so wenig wie möglich abverlangen. Der Server soll hackeln, der Client soll präsentieren.

Zitat von gelbasack

Zu PHP sag ich nichts...

*flame*

Zitat von DomiN

Der Server soll hackeln, der Client soll präsentieren.

bei wenigen (hier: 3) clients mag das ja stimmen, wenns mal in die richtung von hunderten clients geht gilt genau das gegenteil: mach nix am server, was der client auch kann.
gut, vielleicht nicht wirklich alles. es gibt z.b. einige websites, die daten nur clientseitig auf konsistenz überprüren, wenn man dann javascript ausschaltet kann man interessante dinge anstellen

Zitat von sutupud

bei wenigen (hier: 3) clients mag das ja stimmen, wenns mal in die richtung von hunderten clients geht gilt genau das gegenteil: mach nix am server, was der client auch kann.

Sag das mal den World of Warcraft-Programmierern, die eifrigst gegen Cheater kämpfen

Zitat von sutupud

bei wenigen (hier: 3) clients mag das ja stimmen, wenns mal in die richtung von hunderten clients geht gilt genau das gegenteil: mach nix am server, was der client auch kann.
gut, vielleicht nicht wirklich alles. es gibt z.b. einige websites, die daten nur clientseitig auf konsistenz überprüren, wenn man dann javascript ausschaltet kann man interessante dinge anstellen

Jetzt wirds schon spezifischer.
Wie du beschrieben hast, gehts mir da wirklich um den Sicherheitsaspekt.
Wenn der Client etwas berechnet und an den Server schickt muss der Server die Berechnungen verifizieren bevor weiterverarbeitet wird. Dazu muss der Server die Sachen im schlimmsten Fall selbst neu berechnen. Damit kann man es sich am Client sparen. Wir wissen alle, dass wir keine Daten ungeprüft annehmen.
Wenn wir hier von einer Warenwirtschaft reden, wird das erste Bottleneck die Datenbank sein. Die kann ich sowieso nicht auf die Clients auslagern. Die Postgres ist da richtig nett beim skalieren.

Zitat von DomiN

Wie du beschrieben hast, gehts mir da wirklich um den Sicherheitsaspekt.

das meine ich ja mit "nicht alles", dass datenprüfung am server gemacht werden sollte wollte ich auch mit dem beispiel ausdrücken, das ich angeführt habe.
ich habe eher an gewisse berechnungen gedacht, berechne ich daten oder sende ich die rohdaten gleich an den client und lasse den rechnen. sicher gibt es hier auch weitere aspekte: sicherheit, datenvolumen, etc.
es gibt einfach situationen, wo man den server nicht mit dingen belasten soll, die der client auch sinvoll machen kann.

Hmm. Ist aber eher unüblich, dass der Client mehr Daten bekommt als er braucht. Man kann imo ruhig den Server arbeiten lassen. Der Einsatz von ThinClients ist bei Warenwirtschaftsys gar nicht so abwegig - daher auch Rechenlast evntl. auslagern (in diesem Beispiel).

Zitat

Wenn wir hier von einer Warenwirtschaft reden, wird das erste Bottleneck die Datenbank sein. Die kann ich sowieso nicht auf die Clients auslagern. Die Postgres ist da richtig nett beim skalieren.

Wenn PgSQL bei 3 Clients schon in die Knie geht hätten wir ein Problem *g*

Zitat von spotnik

ich möcht mit einem Link (oder Button) auf der php seite die rechnung in der datenbank speichern und drucken, ohne drucker-dialogfenster

Wenn du den Link anklickst, dann wird ein PDF $irgendwo abgespeichert. $irgendwoanders läuft ein Programm (in meinem Fall ein wsh-script) welches $irgendwo nach neuen pdf-dateien überwacht, bei Fund druckt und danach löscht.

Die meisten "gescheiten" Firmen-Netzwerkdrucker lassen sich direkt aus php vergewaltigen. (etwas Trickreich, aber extrem ligthweigth)

http://de.php.net/ps
http://de.php.net/manual/de/function.socket-connect.php

Würde auch zu einer PHP oder einer anderen (JSP, ASP .NET,...) greifen. Das Problem bei Client Applikationen ist halt, du schickst SQLs an den SERVER. Wird vielleicht bei dir nicht der Fall sein, könnte aber dann schon mal passieren, dass da jemand SQL Injection oder andere Spielerein vor hat. (Da die SQLs ja am Client prepared werden) Es gibt auch oft Befehele und unterstüzung DB-seitig sowas zu vermeiden (MySQL hat sowas wenn ich mich nicht täusche, muss aber explizit gemacht werden), sonst müsstest erst Recht einen serverseitigen Dienst laufen lassen, der dir das macht.

Außerdem hast dann noch das Problem, dass du einen (meherere) User anlengen musst und damit kann dann schon viel Unfug betrieben werden (vor allem da entweder den Usern diese Daten bekannt sein müssen oder in irgendeiner Form (Registry, Files, ODBC) am Client gespeichert sein müssen, Serverseitig nicht, da steht alles in deinem PHP/JSP/APS .NET -file oder sonst wo, und es braucht auch niemand anderer außer dein Server darauf zuzugreifen.

Es wäre aber auch eine Kommunikation mit Java/C oder einem anderen Client möglich und der übergibt dann parameter fürs schreiben an eine Serverpage (PHP/JSP). Der Client könnte dann einfach nur Lese-Rechte auf die Datenbank haben. Mit C/Java könntest dann auch schön auf Drucker/Barcodescanner zugreifen. Selbst bei Thin-Clients wäre das nicht schlimm da diese dann am Server-Laufen( das einzige Problem sind dann die lokalen Geräte, falls die nicht mitgemappt werden)

mfg Schakal

mfg Schakal