Wie schon gesagt. Ich kann nur Ratschläge geben, die Entscheidungen liegen bei dir.

Zurück zu der langen Zeile.
Könntest du das "read_ ....whatever" so anpassen dass es nur die Daten liefert die angefordert werden?
Etwas in der Art:

Das würde an einigen Stellen sicher "Platz" sparen, in mehrfacher Hinsicht.

Das Zerstückeln des Scriptes macht nur begrenzt Sinn, da im Extremfall jedes mal ein neuer Interpreter gestartet werden muss, das kann bei kleinen Scripten die Zeit zum Parsen des Scriptes bei weitem übersteigen. Selbst wenn man "mod_perl" in Apache nutzt, machen große Scripte mehr Sinn. Dazu kommt dann, dass man viel Code dublizieren muss. (einbinden von Modulen z.B.) Da schleichn sich leicht Fehler ein.

Dein Argument, der schlechten Editierbarkeit, einer Datenbank, ist nur begrenzt richtig.
Du könntest, z.B. die Dateien als Referenzen behalten und überwachen, ob sie sich ändern. Bei einer Änderung lädst du die Daten erneut in die Datenbank. Bei Änderungen in der Datenbank würde die Dateien neu geschrieben. Das könnte ein unabhängiges Script machen. Damit blieben die Daten in den Dateien und der Datenbank Synchron, du könntest aber die Vorteile einer DB nutzen.
Weiterhin wären die Daten doppelt gesichert. Bei einer Beschädigten Datei könnte man sie aus der DB wieder herstellen. Bei Einem Fehler in der DB, wäre es ein leichtes ein Backup aus der Datei ein zu spielen.

>>Das Zerstückeln des Scriptes macht nur begrenzt Sinn....<<

Das habe ich auch angenommen, nachdem ich mich mit dem UA-Script befasst habe. Ein autonomer Script sogar für das Anfordern eines vergessenen Passworts und dergleichen... UA war übrigens bis v3.6x auch nichts anderes als ein aufgemotztes Everyauction DB GPL Derivat.

Ähnlich wie das gewaltige Template-Management, vor Allem wenn man sieht wieviele "Code-Sachen" im (admin-editierbaren) HTML Text eingebunden sind. Da braucht einer nur etwas daran zu ändern, und dann funzt diese Seite garantiert nicht mehr und ein Anruf bei UA wird fällig....

Es macht doch genau so wenig Sinn, eine externe Template für 8 Zeilen Text aufzurufen, da geht es sicher schneller, die Zeilen unter "qq|" oder ähnlich im Script zu "verpacken", auch wenn solches natürlich bei möglichen nachträglichen Anpassungen etwas intransparenter zu handlen ist als eine Template.

Demo Admin Seite von UA

Aber man kann vielleicht auch zuviel machen wollen. Heutige Dual-Core Dedicated's mit Gigas of RAM verzeihen heute vieles, was vor wenigen Jahren noch zum Server Overload führen konnte...

---
Bezüglich langer Linie:

Die Länge der $variable-Zeilen kann ich schon anpassen. Ich mach das zum Beispiel bei:



Der Artikelstamm wird immer vollständig eingelesen, da möglicherweise der benötigte $Variable-Wert erst in Zeile 49 von 50 eingetragen ist, und daher alle darüberstehenden Zeilen vorgezählt werden müssen, sonst wird die falsche Zeile gelesen und deren Inhalt dargestellt, oder, je nach Content Filterung, eine Fehlerseite produziert.

---

Noch etwas Technik. Ich produziere gelegentlich Reg-Dateien ohne Titel. Das kommt, weil noch nicht alle Dinge "geschaltet" sind. Ich möchte diese Nuller automatisch löschen, denn sie verfälschen u.A. Zähler-Ergebnisse und ich erhalte in der Benutzer-Indexliste einen Eintrag ohne Benutzernamen. Ich möchte aber nicht diesen Eintrag unterdrücken, sondern die Nuller Datei sofort löschen.

Die Datei heisst:

.dat

anstelle von:

Whoever.dat

Zum Lesen der Dateien wird diese Routine gebraucht:



Ich nehme an, dass es irgend etwas derartiges braucht, um den Nuller zu löschen:



aber ich hab's bislang noch nicht fertig gebracht, weil vor und nach ".dat" noch was rein muss was ich wieder einmal nicht weiss.

Etwelche Hilfe würde bestens verdankt.

Ein schönes Wochenende

Ernie

Das Löschen der Nuller könnte so aussehen:

MfG

Das ist eine Zuweisung. Es wird der Variable "$file" der Inhalt des Barwords ".dat" zugewiesen.
Bei "use strict" müsste das eigentlich auffliegen.
Ein Stringvergleich erfolgt mit "eq" allso "if($feil eq '.dat')"

Ich habe eine ganz einfache Lösung gefunden.



Liest die Länge des Dateinamens inklusive Punkt und Endung und löscht alles, was kürzer als '6' ist. Da mit Ausnahme der .htaccess Datei in diesem Verzeichnis nichts anderes enthalten ist, sollte das ausreichen.

Gut so!

Oder habe ich etwas übershen?

Ernie

und warum nicht so?

den namen kennst du doch und den pfad auch.
einfach direkt löschen.
eine fehlermeldung würde zwar in $! stehen, aber brauchst du ja nicht abfragen.

...kaum ist man einmal stolz darauf, überhaupt eine Lösung für ein Problem gefunden zu haben, kommt schon einer der es noch viel einfacher kann... !

Zuerst als ich es las, hab ich geglaubt, etwas ähnliches bereits versucht zu haben, aber möglicherweise ohne Klammern.

Anyway, ich habe damit meine Benutzer-Indexierung funktionsfähig. Damit kann ich jetzt Abläufe verbessern, die vorher mit dem populären EA-Indexer FastEA nicht oder nur "auf Umwegen" getätigt werden konnten. Somit kann ich den "read-only" Zugriff auf die eigentlichen User-Reg-Dateien massiv reduzieren, und erst noch alle Benutzer Infos von "einem einzigen Blatt" ablesen. Sozusagen eine "VSSQLDDB" (very small SQL Derivate DB).

Im damaligen EA Script-Forum wurde das Thema Indexierung nur sehr rudimentär behandelt. Alle redeten über Indexierung, aber keiner lieferte viel nützliches dazu. Man befürchtete vielleicht, dass solche Tip's von anderen sowieso nur wieder zu Bargeld gemacht würden. Typisches GPL-Syndrom...



Ernie

Wir sollten damit vielleicht diesen Thread damit beenden, sonst artet er aus...
Ich werde gern problemspezifisch wieder im Forum anklopfen.

Auctioneer+2008-10-05 02:09:27--

Ich werde gern problemspezifisch wieder im Forum anklopfen.

Gut zu wissen ;-)