EisFuX: Feature-Request an die Community

Beitrag lesen

(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