Office: WebServer Erfahrung

Hi Markus,

das ist so richtig.
allerdings solltest du ungebunden arbeiten und komplizierte Schreibvorgänge in transaktionen kapseln, damit Du keinen "Datensalat" bekommst, wenn die Verbindung abbricht.

VG
trekking

 

PHP:

         <?php

$sql = "SELECT feld1, feld2, feld3 FROM tabelle WHERE Key=".$_GET['TheKey'];

foreach ($pdo->query($sql) as $row)
{
echo $row['feld1'].chr(2).$row['feld2'].chr(2).$row['feld3'].chr(3);
}

?>          

 

Bezüglich Transaktion verwendest du die des Servers oder die der Connection?

 

\@Jones,
hast du so was schon mal eingesetzt, oder war das eine spontane Idee?
Änderungen würdest du dann auch auf diesem Weg durchführen?
Die Daten wären dann aber nicht verschlüsselt oder?
Jetzt bleibt dann nur noch die Frage, wie die Performance aussehen würde.
Jedenfalls ein ungewöhnlicher Ansatz.

 

Ich benutze das aktiv, allerdings unter anderen Bedingungen.
Intranet/ASP/AccessDB/ADO/NetClient

Auf des ASP-Seite ist das mit ADO schön einfach:

Code:

Mit trusted security kann ich den Zugriff auf dem Server leicht absichern,
darum benutze ich einfach die Möglichkeit den SQL-String als Parameter
zu übermitteln. Dazu gibt es eine (aufwendige) StorageAccess-Klasse, die
mir alle weiteren Zuweisungen abnimmt. Anschließend steht mir ein
StorageAccessContainer zur Verfügung um auf die Felder zuzugreifen.

Das läuft einwandfrei und macht eine AccessDB quasi zu einem SQL-Server.
Das Performance im Netz ist besser als der direkte Zugriff auf die MDB.
(MultiUser, komplexe Abfragen)


Edit:
Im oberen Beispiel habe ich dir eine https-Adresse spendiert,
weshalb die Daten verschlüsselt übermittelt werden.


Gruss
Jones

 

Für das Speicher benutze ich dedizierte Funktionen pro Tabelle.
Teileweise sind die Zugriffe dann auch per Hash gesichert,
damit nicht irgendwie per Batch Unsinn gemacht werden
könnte. Zugriff hat ohnehin nur der, der auch das Recht
dazu hat.

Hier noch ein Bespiel für ein variables beschreiben von geänderten
Feldwerte. Die nötigen Parameter liefert mein Klasse automatisch.

Code:

 

Hi Markus,

ich verwende die connection Transaktion. Mit stored Procedures könntest Du dies auf den Server verlegen. Da ich bisher allerdings immer noch nicht sicher bin ob ich MySQL ewig an der Stelle verwende habe ich es bisher immer im FE gemacht. die Performance ist auf dem Server zwar besser aber wenn ich ehrlich bin, fällt das meist nicht auf *Smilie


@Catboy
Bekommst von mir nen Like *Smilie

VG
trekking

 

Sieht grundsätzlich interessant aus.

Wie wäre es mit rs.save und den Bytestream daraus zu übergeben?
Dann würde man sich doch das ganze zerlegen und zusammenkleben ersparen?

Bei der getString Methode von ADODB, wächst der Zeitbedarf im Gegensatz zu getRows nicht linear mit der Datenmenge. Die Methode dürfte schlecht implementiert sein. Bei größeren Datenmengen dauert das ewig im Vergleich zu getRows. Wenn man das selbst mit etwas Intelligenz nach dem Beispiel einer stringbuilder Klasse wie in .net zusammenbaut ist man um ein vielfaches schneller.

LG Markus

Im Test dauert die Übergabe via Stream mit 1000 Datensätzen mit gemischtem Inhalt und 10 Spalten im Mittel ca 7 Millisekunden.
Also rein das Speichern des Recordsets als Stream und zurück.
Vor allem ist das jeweils eine Zeile Code.

 

\@markus

Wenn man 1:1 ein Recordset übertragen möchte, ist die Save-Methode auf
jeden Fall zu bevorzugen (mit adPersistADTG).

Dass GetRows schneller ist, bringt glaub ich nichts, weil man nicht an
die Daten ran kommt, ohne zusätzlichen Zeitaufwand. Das Array zu
übertragen dauert in der Summe vmtl. länger als mit GetString().

Für meine Anwendung ist GetString() am besten, weil ich nur kleinere Datenmengen
abrufe. (ADO.NET verwende ich prinzipiell nicht, außerdem
kann es kein ADTG importieren.)

Wie immer, hat alles seine Grenzen, man muss eben schauen, was für
die jeweilige Anwendung am besten passt.

Azure mit SQL-Server ist für Dein Vorhaben die Königsklasse! *Smilie

Gruss
Jones

 

\@CatboyJones,
die Übertragung des Recordsets als Stream war nur ein Gedankenanstoß um die Performance zu verbessern. Abwägen muss dass immer der Entwickler.

Danke jedenfalls für Deine Beiträge zu dem Thema.
LG M

 

Wir arbeiten hier schon seit Jahren mit MySQL... zweiter Standort ist via OpenVPN angebunden... Vorteil dabei ist, dass nicht nur MySQL Dateneinträge sondern auch verlinkte Dokumente (PDF, Bilder etc.) übertragen werden können...
Anfangs lief es dank mickriger Upload Leitung etwas langsam, mittlerweile (Flaschenhals ist Upload 2Mbit bei der Gegenstelle) aber zufriedenstellend und vor allem stabil!

 

\@Joda78, danke.
Kannst du etwas über die Geschwindigkeit beim Arbeiten sagen?

 

Ich habe es so programmiert, dass ausschließlich mit Recordsets (DAO) gearbeitet wird... so sind wir gut zufrieden. Eingaben müssen mit einem "Speichern" Button in die Datenbank zurückgeschrieben werden...
Leichte Verzögerungen sind vorhanden, aber nicht tragisch - Upload 2 Mbit, Download 16 MBit (Flaschenhals auf einer Seite), damit dauert es gefühlt ca. 3-4 Mal so lange als am Serverstandort.
Man kann Aufträge eingeben, Lagerdaten transferieren etc. - solange man keine (verlinkten) Bilddaten öffnet, absolut okay.

 

Hallo

mysql ist nicht so unsicher wie es scheint - du musst es halt nach außen komplett dicht machen so dass nur deine lokal laufendes Frontend darauf zugreifen kann.

Ich betreue hier nen Server mit vorgeschalteter HW Firewall - da ist wirklich nur HTTP und HTTPS nach außen offen - die bespielung von MYSQL mittels Access findet über einen Tunnel statt ...

Sicher - nicht ist zu 100% dicht - wenn du pech hast - und dein Frontend Script unsauber ist oder der Angreifer eine Sicherheitslücke im Apache ausnutzt dann kann immer was passieren - das hat aber nix mit MYSQL zu tun....

Ich würde jetzt mysql oder mariadb auch nicht nach außen aufmachen ... das wäre mir zu heikel ....

Nachtrag: selbst über schnelle Leitungen ist das übertragen großer Datenmengen von einem lokal liegenden Access (odbc Tabelle) zu einem entfernten SQL Server relativ lahm - ich hab jetzt alles auf Passtrough geändert - nun geht´s deutlich schneller trotzdem das dafür nicht gemacht ...

 

GTRDRIVER & Joda78 danke für die Infos.
Das es nichts Sicheres gibt ist mir klar. Das wird dann das Hauptthema für den Hoster.