Feature-Request an die Community

[Tom]

Hello,

ich brauche Eure "philosphische Unterstützung".

nebenbei habe ich ein kleines Modul als Include für PHP gebastelt, um für kleine Webseiten mit ganz wenigen Handgriffen eine Benutzerverwaltung, ein "Login", eine "Onlineanzeige", und alle notwendigen Dateifunktionen für den Aufbau eines Gästebuches oder eines kleinen Boards realisieren zu können.

Die Dateiverwaltung soll kein SQL-Lite werden, aber ein paar sinnvolle Funktionen benötigt sie schon. Und das ist jetzt meine Frage: was ist sinnvoll oder was müsste man dringend haben?

Einige Befehle existiern rudimentär

"Select"

Man kann Datensätze durch Eingabe eines Schlüsselwertes ausfiltern
   Wenn man mehr als ein Feld des (varianten) Such-Datensatzes
   ausfüllt, werden diese Werte ebenfalls berücksichtigt (AND), die
   Ergebnismenge also weiter eingeschränkt

braucht man eine Case-Insentive Suche?
   braucht man eine Teilfeldsuche "fängt mit ... an"
   braucht man eine Sequenzsuche (LIKE)

was wahrscheinlich auf jeden Fall benötigt wird, ist eine Möglich-
   keit "Offset" und "Limit" nachzubilden für listenweises
   sortiertes ausgeben.

Wird die Sortierung über eine beliebige Spalte ausreichend sein?
   Sonst wird es nämlich wirklich heftig.

"Update"
   Ein Update eines Datensatzes ist bisher nur über eine Schlüssel
   spalte möglich, wobei jede Spalte Schlüsselspalte sein kann
   Das erste genannte Feld im Update-Array ist automatisch
   Schlüsselspalte. Ist diese UNIQUE (siehe Insert) gibt es ja
   nur einen Treffer, sonst wird bisher der erste Treffer
   verändert.

Da ich mit möglichst wenigen Übergabeparameter auskommen wollte,
   hat sich diese Lösung so entwickelt. Mit Update bin ich aber noch
   nicht glücklich. Wenn man eine andere als die "UNIQUE"-Spalte
   zum Suchen benutzt, ist es im Prinzip möglich, auch doppelte
   Werte in die UNIQUE-Spalte zu bringen.

Das könnte man durch "feste Verdrahtung" z.B. von "ID" für die
   Unique-Spalte verhindern. Es soll in der Bedieung einfach
   bleiben, also suche ich Super Ideen ;-))

"INSERT"
   Man kann beliebige Datensätze einfügen.
   Das erste Feld des Datensatzes (Array) wird automatisch als
   UNIQUE betrachtet. Insert wehrt sich dann, wenn der Wert schon
   vorhanden ist.

Da die Tools dafür da sind, mit wenigen Handgriffen eine kleine
   Page ohne Datenbank hochzuziehen, könnten Feldnamen wie 'nickname'
   oder 'id' locker fest verdrahtet UNIQUE werden.

Oder sollte ich Namens-Präfixe nehmen für bestimmte Funktionen?
   Die würde ein Anfänger am Anfang weglassen, bis er merkt, was
   sie bewirken.

"DELETE"
   gelöscht werden alle Datensätze, auf die das Muster laut
   'select' passt, also über alle Felder mit AND verknüpft

Man bekommt zurückgemeldet, wieviele betroffen waren
   Enthält ein Datensatz ein feld nicht (Da die Satzaufbauten ja
   variant sind) kann es eben auch nicht für die Einschränkung
   herangezogen werden.

Sollte man das umdrehen? Wenn das Feld nicht im Satz vorhanden
   ist, flirgt er aus der Treffermenge raus?

Dieses "Kernel" soll dabei möglichst offen bleiben und keine Funktion angehängt bekommen, die durch einen Wrapper bestens gelöst werden könnte.

Es berücksichtigt das vieldiskutierte Locking.
Zusatzfunktionen wie den Schutz bei zeitversetztem Lesen und Schreiben muss ein Wrapper erledigen und könnte er bisher sowohl mittels hash als auch mit der mtime oder auch mit einem Schreibzähler bis auf Satzebene hinunter.

Dann wird es aber schon wieder komplex.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[EisFuX]

(H[ae]llo|Hi(ho)|Tag) Tom,

Hello,

ich brauche Eure "philosphische Unterstützung".

nebenbei habe ich ein kleines Modul als Include für PHP gebastelt, um für kleine Webseiten mit ganz wenigen Handgriffen eine Benutzerverwaltung, ein "Login", eine "Onlineanzeige", und alle notwendigen Dateifunktionen für den Aufbau eines Gästebuches oder eines kleinen Boards realisieren zu können.

Interessant.

Die Dateiverwaltung soll kein SQL-Lite werden, aber ein paar sinnvolle Funktionen benötigt sie schon.

Darf man fragen, was gegen einen einen Einsatz des echten SQLite spricht? Das ist doch die ideale[1] Datenbank-Engine für (kleinere) Websites.

[1] mvuMn ;-)

MffG
EisFuX

[Tom]

Hello,

Darf man fragen, was gegen einen einen Einsatz des echten SQLite spricht? Das ist doch die ideale[1] Datenbank-Engine für (kleinere) Websites.

Es sollte selber aufgebaut werden mit den Mitteln, die PHP bietet, weil es Bestandteil eines Lernprojektes ist.

Wenn man sich da jetzt stattdessen durch ca. 100kByte C-Code wühlen soll, ist das nur noch 'was für extrem Fortsgeschrittene.

Darum soll es ja auch einfach bleiben, also nur die wichtigtsten Funktionen abbilden.
Dadurch, dass die Daten als serialisiertes Array in einer Datei gespeichert werden, ist sowieso bei typisch 100.000 bis maximal 500.000 Bytes Daten Schluss.

Es gehört also dazu, herauszufinden, welche Features man benötigt und wie die umgesetzt werden können. Die sollten dann nachher auch möglichst bequem nutzbar sein, also quasi ein

htmlstring  make_whoisonline($deltatime)

liefert dann den fertigen HTML-String für die "Online-Box" inclusive anklickbarer Links auf das "Profil" des Users.

Es geht darum, die Funktionen an den richtigen Stellen zu schneiden.

Ich bereite ein Seminar vor. Das soll im Frühjahr laufen über zwei Wochen (28. Mrz bis 10. Apr). Die beiden Trainer (Lehrer) erwarten von mir gute Ideen ;-)

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[EisFuX]

(Hallo|Hi(ho)|Tag) Tom,

tschuldige, dass ich nochmals nerve ...

Darf man fragen, was gegen einen einen Einsatz des echten SQLite spricht? Das ist doch die ideale[1] Datenbank-Engine für (kleinere) Websites.
Es sollte selber aufgebaut werden mit den Mitteln, die PHP bietet, weil es Bestandteil eines Lernprojektes ist.

Die SQLite-Extension ist seit Version 5 Bestandteil von PHP -- die Informationen auf der deutsche Handbuchseite sind offensichtlich nicht mehr aktuell. Das "Wühlen durch C-Code" dürfte damit entfallen.

Darum soll es ja auch einfach bleiben, also nur die wichtigtsten Funktionen abbilden.

Ja, und eine "richtige" Datenbank spart eben das ganze Gewurstel (auf PHP-Ebene) mit dem File-Locking und dem Synchronisieren des Datenbankinhaltes, wenn mehrere Threads zeitversetzt lesen und schreiben usw. Man könnte sich so auf das Wesentliche konzentrieren und müsste sich nicht mit solchem "Kleinkram" abgeben.

Ich bereite ein Seminar vor. Das soll im Frühjahr laufen über zwei Wochen (28. Mrz bis 10. Apr).

Und da das Seminar im Frühjahr 2008 stattfindet, brauchst du ja auf PHP4 (also das PHP ohne serienmäßiges SQLite) auch keine Rücksicht mehr zu nehmen. ;-)

Die beiden Trainer (Lehrer) erwarten von mir gute Ideen ;-)

Sie selbst haben wohl keine?

MffG
EisFuX

[Tom]

Hello,

Die beiden Trainer (Lehrer) erwarten von mir gute Ideen ;-)
Sie selbst haben wohl keine?

Sie haben Vorstellungen, was man machen könnte.
Aber ein Seminar von zwei Wochen Dauer vorzubereiten, erfordert schon einen Menge Zeit.
Das können Lehrer neben ihrem normalen Unterrichtsstoff nicht mehr leisten und das meine ich tatsächlich so!

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[EisFuX]

(Hallo|Hi(ho)|Tag) Tom,

ich brauche Eure "philosphische Unterstützung".

... offensichtlich sind kaum Philosophen anwesend, also versuch ich es mal ... ;-)

nebenbei habe ich ein kleines Modul als Include für PHP gebastelt, um für kleine Webseiten mit ganz wenigen Handgriffen eine Benutzerverwaltung, ein "Login",...

Vielleicht würde dein Posting in einem Forum oder Board auf mehr Interesse stoßen, in dem sich Leute treffen, welche die Zielgruppe eines Seminars zu diesem Thema darstellen.

eine "Onlineanzeige", und alle notwendigen Dateifunktionen für den Aufbau eines Gästebuches oder eines kleinen Boards realisieren zu können.

War die "Onlineanzeige" jetzt nur einfach zu realisieren, oder wollte die jemand unbedingt haben? Ich sehe nicht wirklich Sinn in solchen Features, aber viele Web-Meister stehen ja auf sowas ... ;-)

Die Dateiverwaltung soll kein SQL-Lite werden, aber ein paar sinnvolle Funktionen benötigt sie schon. Und das ist jetzt meine Frage: was ist sinnvoll oder was müsste man dringend haben?

"Select"

Man kann Datensätze durch Eingabe eines Schlüsselwertes ausfiltern
   Wenn man mehr als ein Feld des (varianten) Such-Datensatzes
   ausfüllt, werden diese Werte ebenfalls berücksichtigt (AND), die
   Ergebnismenge also weiter eingeschränkt

braucht man eine Case-Insentive Suche?

Da du die Suche in einem Array veranstaltest: Wäre preg_match() schnell genug?
Da implementiert sich wahlweise Case-(In-)-Sensivität ziemlich einfach.

braucht man eine Teilfeldsuche "fängt mit ... an"
   braucht man eine Sequenzsuche (LIKE)

... und das beides auch.

was wahrscheinlich auf jeden Fall benötigt wird, ist eine Möglich-
   keit "Offset" und "Limit" nachzubilden für listenweises
   sortiertes ausgeben.

Klar, für seitenweise Darstellung von Gästebucheinträgen und Boards. Also: Ja.

Wird die Sortierung über eine beliebige Spalte ausreichend sein?

Wenn man beispielsweise die Liste der Benutzer durchsuchbar machen möchte, dann
könnte eine Suche mit mehreren Kriterien sehr nützlich sein: "Benutzername",
"Wann-angemeldet", "Ist-online-oder-nicht", ...
Ähnliches dürfte für eine brauchbare Suche in einem Message-Board gelten.

Sonst wird es nämlich wirklich heftig.

Warum? Würde das das Script zu sehr verlangsamen? Wenn du mit einem (re)serialisierten
Array arbeitest, steht doch sowieso schon die ganze Tabelle im Hauptspeicher ...

"Update"

Ließe sich UPDATE nicht durch eine (geschickte, wegen Locking und so) Kombination aus
SELECT, DELETE und INSERT ersetzen?

Ein Update eines Datensatzes ist bisher nur über eine Schlüssel
   spalte möglich, wobei jede Spalte Schlüsselspalte sein kann
   Das erste genannte Feld im Update-Array ist automatisch
   Schlüsselspalte. Ist diese UNIQUE (siehe Insert) gibt es ja
   nur einen Treffer, sonst wird bisher der erste Treffer
   verändert.

Da ich mit möglichst wenigen Übergabeparameter auskommen wollte,
   hat sich diese Lösung so entwickelt. Mit Update bin ich aber noch
   nicht glücklich. Wenn man eine andere als die "UNIQUE"-Spalte
   zum Suchen benutzt, ist es im Prinzip möglich, auch doppelte
   Werte in die UNIQUE-Spalte zu bringen.

Das könnte man durch "feste Verdrahtung" z.B. von "ID" für die
   Unique-Spalte verhindern. Es soll in der Bedieung einfach
   bleiben, also suche ich Super Ideen ;-))

Hmm, du saßt vor deinem Quelltext und hast das hier geschrieben. Deshalb
ergibt das für dich Sinn. Ich dagegen kann nicht auf diesen Quelltext
zurückgreifen. Deswegen (oder weil ich zu blöd bin), kann ich das irgendwie
nicht sinnvoll einordnen. Vielleicht mal an einer Beispiel-Tabelle erklärt, könnte das aber noch was werden ...

"INSERT"
   Man kann beliebige Datensätze einfügen.
   Das erste Feld des Datensatzes (Array) wird automatisch als
   UNIQUE betrachtet. Insert wehrt sich dann, wenn der Wert schon
   vorhanden ist.

Da die Tools dafür da sind, mit wenigen Handgriffen eine kleine
   Page ohne Datenbank hochzuziehen, könnten Feldnamen wie 'nickname'
   oder 'id' locker fest verdrahtet UNIQUE werden.

Oder sollte ich Namens-Präfixe nehmen für bestimmte Funktionen?
   Die würde ein Anfänger am Anfang weglassen, bis er merkt, was
   sie bewirken.

Könntest du näher ausführen, um welche "Funktionen" es hier geht?
Und auch um welche Namens-Präfixe? (oder Präfizes? ;-))

Als Anwender wäre mir übrigens am liebsten, dass ich (wenigstens) eine
beliebige Spalte der Tabelle als PRIMARY_KEY definieren könnte. Und falls
ich das nicht tun würde, wäre es mir lieb, wenn die Datenbank das intern
selbst mit einer (versteckten) Spalte machen würde. Und noch schöner wäre
es, wenn ich auch jeder anderen Spalte die Eigenschaft "UNIQUE" verpassen
könnte. Im Sinne von Vereinfachung des Scriptes könnte man aber auch die
einzelnen Anwendungsmöglichkeiten darauf abklopfen, ob nicht eine Tabellenspalte mit dieser Eigenschaft genügt: Gästebuch ja, Board ja,
Benutzerliste ja (Benutzername?).

"DELETE"
   gelöscht werden alle Datensätze, auf die das Muster laut
   'select' passt, also über alle Felder mit AND verknüpft

Man bekommt zurückgemeldet, wieviele betroffen waren
   Enthält ein Datensatz ein feld nicht (Da die Satzaufbauten ja
   variant sind) kann es eben auch nicht für die Einschränkung
   herangezogen werden.

Sollte man das umdrehen? Wenn das Feld nicht im Satz vorhanden
   ist, flirgt er aus der Treffermenge raus?

Nein, ich würde das so lassen. Wenn ich alle Datensätze löschen möchte,
die den Vornamen "Karl" enthalten, dann erwarte ich doch, das sowohl
"Karl Ranseier", "Karl Valentin", "Karl Marx", als auch eben jemand,
der nur "Karl" (mit Vornamen) heißt, entfernt wird.

Dieses "Kernel" soll dabei möglichst offen bleiben und keine Funktion angehängt bekommen, die durch einen Wrapper bestens gelöst werden könnte.

Es berücksichtigt das vieldiskutierte Locking.
Zusatzfunktionen wie den Schutz bei zeitversetztem Lesen und Schreiben muss ein Wrapper erledigen und könnte er bisher sowohl mittels hash als auch mit der mtime oder auch mit einem Schreibzähler bis auf Satzebene hinunter.
Dann wird es aber schon wieder komplex.

Hierzu sage ich nur: Siehe meine Bemerkungen zu SQLite ... ;-)

MffG
EisFuX

[Tom]

Hello,

ich brauche Eure "philosphische Unterstützung".

... offensichtlich sind kaum Philosophen anwesend, also versuch ich es mal ... ;-)

Das waren hier früher erheblich mehr!

Vielleicht würde dein Posting in einem Forum oder Board auf mehr Interesse stoßen, in dem sich Leute treffen, welche die Zielgruppe eines Seminars zu diesem Thema darstellen.

Hab ich auch schon gedacht. Aber da lesen die Schüler sicher alle mit :-)

War die "Onlineanzeige" jetzt nur einfach zu realisieren, oder wollte die jemand unbedingt haben? Ich sehe nicht wirklich Sinn in solchen Features, aber viele Web-Meister stehen ja auf sowas ... ;-)

Nein, die soll dafür benutzt werden, um mit demjenigen (per Link) direkt Kontakt aufnehmen zu können.

Wird die Sortierung über eine beliebige Spalte ausreichend sein?
Wenn man beispielsweise die Liste der Benutzer durchsuchbar machen möchte, dann
könnte eine Suche mit mehreren Kriterien sehr nützlich sein: "Benutzername",
"Wann-angemeldet", "Ist-online-oder-nicht", ...
Ähnliches dürfte für eine brauchbare Suche in einem Message-Board gelten.

Sonst wird es nämlich wirklich heftig.
Warum? Würde das das Script zu sehr verlangsamen? Wenn du mit einem (re)serialisierten

Dann würde man die Benutzerdefinierten Funktionen zur Sortierung benutzen müssen.
Preg_match() und usort() sind eigentlich schon eine Nummer zu hoch.

"Update"
Ließe sich UPDATE nicht durch eine (geschickte, wegen Locking und so) Kombination aus
SELECT, DELETE und INSERT ersetzen?

Es wird so arbeiten, wie Select.
In einem Übergabeparameter werden also _nur_ die Felder mit den Suchbegriffen übergeben

Das was man dann ausfiltert, wird mit den Werten aus einen extra-Parameter überschrieben

Als Anwender wäre mir übrigens am liebsten, dass ich (wenigstens) eine
beliebige Spalte der Tabelle als PRIMARY_KEY definieren könnte.

Die müsste auch feststehen. Ist klar. Also muss man der Tabelle doch diverse Metainformatioen einbauen, die tunlichst mit abgespeichert werden. So komplex sollte es nicht werden für den Anfang.

"DELETE"
   gelöscht werden alle Datensätze, auf die das Muster laut
   'select' passt, also über alle Felder mit AND verknüpft

Man bekommt zurückgemeldet, wieviele betroffen waren
   Enthält ein Datensatz ein feld nicht (Da die Satzaufbauten ja
   variant sind) kann es eben auch nicht für die Einschränkung
   herangezogen werden.

Sollte man das umdrehen? Wenn das Feld nicht im Satz vorhanden
   ist, flirgt er aus der Treffermenge raus?
Nein, ich würde das so lassen. Wenn ich alle Datensätze löschen möchte,
die den Vornamen "Karl" enthalten, dann erwarte ich doch, das sowohl
"Karl Ranseier", "Karl Valentin", "Karl Marx", als auch eben jemand,
der nur "Karl" (mit Vornamen) heißt, entfernt wird.

Das würde auch gehen. Da müsste man bei den Suchparametern einfach kein Feld für den Nachnamen übergeben. Aber wenn man eines z.B. für BERUF drin hätte, aber einzelne Datensätze haben (noch) kein Feld Beruf, dann bestand die Frage, fliegt der raus aus der Treffermenge, weil sein BERUF ja Quasi NULL ist und nicht verglichen werden kann, oder bleibt er drin?

Wenn ich ein zusätzliches Feld zur Eingrenzug der Treffermenge angebe und im Datensatz steht dafür aber nur NULL, erwarte ich dann beim LÖSCHEN, dass er weiterhin zur Menge gehört oder nicht?

Hierzu sage ich nur: Siehe meine Bemerkungen zu SQLite ... ;-)

Es geht gerade um den Umgang mit Daten und Dateien. Den kann man nicht besonders gut lernen, wenn man damit nicht in Berührung kommt.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom