Hallo, Michael.
Ob mit AND und OR, oder mit + und -, ob mit "...",
alles recht egal, hauptsache, ich kann nach mehreren
Begriffen suchen :)
Erst _nachdem_ Du das festgelegt hast, kannst Du damit _anfangen_, eine entsprechende Lösung zu realisieren
IMHO denkt man nach einiger Zeit genug strukturiert, dass man bei kleinen Programmen (wie in diesem Fall) die Vorüberlegungen schon in einem Arbeitsgang mit dem Schreiben des Codes erledigt. Man hat meist schon automatisch ein Flussdiagramm im Kopf, man stellt sich die verschiedenen Eingaben und die Reaktionen des Programms darauf vor und dividiert dementsprechend die Teilbereiche des Programmes in Funktionen auseinander bzw. legt die Abläufe fest.
Ich habe vor einer Woche genau das realisiert, was Phil gerade plant. Mit dem Markup für das Eingabeformular, welches eine Suche nach zwei Kriterien zulässt (zusätzlich kann der Benutzer UND oder ODER wählen), dem Markup für die Ausgabe der Suchresultate und der Fehlerbehandlung aller Eventualitäten umfasst das Skript 148 Zeilen und ist nicht einmal sonderlich auf Effizienz optimiert.
Hättest du mir geraten, mir erst einmal großartig auszudenken und auf Papier zu notieren, was ich überhaupt vorhabe, bevor ich auch nur die erste Codezeile schreibe, hätte ich deinen Rat wohl nicht befolgt, da es mir zuviel Aufwand für ein solch kleines Programm ist, welches höchstens vierfach bedingt-verschachtelt ist. Ohne die Fehlerbehandlung würde das Formular, eine Schleife, welche die Query konstruiert, und eine Ausgabe ausreichend, ohne Markup sind das 40-50 Zeilen; und eigentlich ist der einzige "Clou" bzw. Kernpunkt des Programmes, eine entsprechende Datenbankabfrage zu generieren.
Vielleicht ist es einfach so, dass man bei einem vergleichsweise unkomplizierten Programm sofort in Anweisungen und Kontrollstrukturen denken kann.
Das ist dann gar nicht mehr arg schwer - aber ohne eine Aufgabenstellung wirst Du der Lösung _dieser_ Aufgabenstellung keinen Schritt näher kommen.
Genau, es ist nicht schwer.
Im Falle von Phil ist der Hinweis es gerechtfertigt (es weiß anscheind wirklich nicht, was er will bzw. denkt nicht in Kategorien der technischen Machbarkeit), es klingt nur ein wenig oberlehrerhaft, auch wenn du vollkommen recht hast. Wenn man das strukturierte Arbeiten einmal gelernt hat und vor allen Dingen weiß, *wie* man ein im Kopf ausgedachtes Programmschema in strukturiertem Code realisiert, kann man sich manche Vorüberlegungen sparen bzw. man erledigt sie automatisch, aber die einzelnen Arbeitsphasen sind dann nicht mehr einfach auseinanderdividierbar.
(Das gilt natürlich nicht, wenn man für andere lesbaren Code schreiben muss - dann zählen die Vorüberlegungen und der Code ist im Endeffekt mehr oder weniger irrelevant, es zählt nur der vom Code abstrahierte Programmablauf, wie du sagst, das ist das Wichtigste und Tatsächliche beim Entwerfen eines Programms - oder das Projekt umfangreicher wird und alles miteinander verzahnt ist.)
Die von dir genannte Vorgehensweise gehört m.E. zu den Grundlagen beim Erlernen von dem Erstellen von Programmen bzw. generell automatisierten Abläufen.
Ich wollte nur anmerken, dass man als Fortgeschrittener viele Arbeitsschritte kombiniert. Vorüberlegungen sind toll, aber damit ein Programm läuft, bedarf es so oder so einer Umsetzung. ;) Vor allem wenn diese Umsetzung keine Herausforderung darstellt, wie es hier der Fall ist, da der eigentliche Programmablauf klar wie Klößchenbrühe ist (ok, ok, "sein sollte" ;)), kann man sich m.E. in diesem Fall problemlos von der traditionellen Arbeitsweise loslösen.
Ich denke einmal, wenn man professionell Software schreibt, treffen meine Überlegungen nicht zu, aber hey, Phil will "nur" ein kleines Suchskript für seine Seite basteln, das muss nicht perfekt sein, auch wenn es ihm gut täte, exemplarisch daran zu lernen, wie man es bestenfalls macht, da er eines Tages möglicherweise dazu gezwungen wird, so zu arbeiten, da sollte ihm diese Vorgehensweise bekannt sein.
Jetzt habe ich mich sooft eingeschränkt, dass nichts mehr übrig bleibt, aber wie gesagt, ich hatte nicht die Absicht, dir zu widersprechen.
Mathias