Beiträge von SinnlosS

Naja, wenn bei jedem Team das hidden-field die gleiche ID hat, woher soll jquery dann wissen aus welchem hidden-Feld es die ID nehmen soll?
Du kannst das hiddenfeld entfernen.
Dann vergibst du in .t_but noch als ID eben die aktuelle id:

<td class="t_but" rowspan="2" id="'.$st8->id.'"></td>

Deine jquery.js änderst du dann folgendermaßen:

$(".t_but").click(function() { 
            var team = $(this).attr("id");  
            $("#team_r").load("lib/team_m.php?"+team); 
        });

$(this) ist genau das td-Element, welches das click-Event auslöst. Damit bekommst du dann über das Attribut "id" die passende ID zurückgeliefert.

Das Beispiel mit dem Koch war auch aus der Praxis gegriffen.
Ich habe letztes Jahr die Homepage für ein Restaurant gemacht, für die der Besitzer und Chefkoch die Texte von einem Werbetexter hat schreiben lassen.

Ok, was Bücher oder Paper angeht, wo dann auch der Autor/Verfasser beisteht, gebe ich dir vollkommen recht.
Ich sehe das mit den SEO-Texten auch etwas skeptisch. Häufig (wenn auch sicher nicht immer) kommen da Texte bei raus die hauptsächlich auf Suchmaschinen optimiert sind und beim menschlichen Leser im besten Fall ein Stirnrunzeln auslösen. Mal davon abgesehen, das suchmaschinen-optimierte Texte auch nicht mehr die gleiche Gewichtung für das Suchmaschinenranking haben wie früher. Da gibt es heutzutage wesentlich effizientere Wege.
Was aber schon mehr Sinn macht ist z.B. das Verfassen lassen von Blogs um diese lebendig zu halten. Und auch generell bei Texten für eine Homepage kann es durchaus Sinn machen, diese von Profi verfassen zu lassen. Nicht jeder hat ein Talent für das Schreiben informativer und verständlicher Texte und das braucht auch nicht jeder. Ein Koch sollte gut kochen können, aber hat beruflich eher seltener Bedarf an eleganten Formulierungen. Wieso soll er selber Texte für seine Homepage verfassen, wenn ihm die jemand anderes viel ansprechender schreiben kann? Das Argument "Wer nicht selber gut formulieren kann sollte auch keine Homepage haben" finde ich halt etwas fragwürdig. Vor allem in einem Thread wo jemand diesen Dienst anbietet braucht man das nicht abzuwerten. Da sollte man es doch jedem potentiellen Interessenten selber überlassen, ob er das als nötig erachtet, oder eben nicht.

Zitat von The User

Wenn ich auf einer Website was zu sagen habe, dann habe ich auch was zu sagen, und wenn nicht, dann lass ich die Webverschmutzung bleiben..

Freut mich wenn du die Zeit für die Ausformulierung aller Texte hast.
Du darfst mir aber gerne glauben, dass das nicht jedem so geht (natürlich nur wenn du möchtest).

Zitat von The User

Och schade.
Aber mal im Ernst: Was soll das ganze SEO-Getexte, wenn die Leute noch nicht einmal nen Text über sich schreiben können…naja, gute Nacht.

Naja, es geht ja nicht nur um die Fähigkeit, sondern auch um den Zeitaufwand. Ich könnte mein Büro auch selber putzen statt eine Putzfrau zu bezahlen. Mach ich aber nicht.

Zitat von Tobse

Ahja, und für 2 Seiten Artikel über XYZ nimmst du dann 3,2 Cent? Geht das pro Zeile, pro Wort, pro absatz?

Textpreise gelten üblicherweise pro Wort.

Zitat von synaptic

und achte auch darauf, dass dein apache (xampp) auch läuft

Dem würde ich mich als Blindtipp anschließen. Xampp gestartet und da dann auch den Apache gestartet?

Zitat von nafets

PS: das Buch heißt PHP 5.3 & MySQL 5.1 "Der Einstieg in die Programmierung dynamischer Websites" geschrieben von Florence Maurice und gedruckt vom Addison Wesley verlag. Ich denk mal das war ausführlich genug :-D:-D:-D
Warte schon gespannt auf eure antwort. mfg

Das kenne ich nicht. Mit Addison Wesley habe ich aber noch keine schlechten Erfahrungen gemacht, auch wenn das letzte Buch da eine Weile her ist.

http://www.blog1.institut1.de/muse-und-muse/

Ich gehe auch mal davon aus, dass du die hallowelt.php im falschen Verzeichnis gespeichert hast. Wenn du sie mit http://localhost/hallowelt.php aufrufen willst, dann muss sie in deinem Xampp-Verzeichnis im Ordner htdocs liegen. Also in .../xampp/htdocs/hallowelt.php

Nur aus Neugier, was für ein Buch hast du dir denn geholt?

Ich bin kein CSS-Experte, aber dass das DIV nicht höher als 800px wird wenn du height:800px; definierst leuchtet sogar mir ein.
Entweder willst du eine min-height, dann nutze die Definition, oder du willst eine feste Höhe, dann nutze height.
Aber nicht beides.

Mal ganz abgesehen davon was Tobse schon geschrieben hat... wie wäre es denn mal einfach wenn du entweder nur < und >= oder nur <= und > verwendest...?

Gegenfrage, hast du mal ein Beispiel wo PHP schneller als SQL ist in Dingen, die von SQL simpel zu erledigen sind?
COUNT() ist schneller als die Ergebnismenge komplett zu selektieren und dann in PHP mit num_rows zu zählen.
SUM() ist zugegebnermaßen nur gleich schnell wie die Zahlen alle auszulesen und in PHP aufzuaddieren. Langsamer als PHP ist es aber definitiv auch nicht.
Datumsberechnungen und -umformungen mit den SQL-eigenen Feldtypen sind wesentlich schneller über die DB, als wenn man diese in PHP vornimmt.
Über das Filtern der Ergebnismenge mit SQL gegenüber dem Auslesen größerer Datenbestände als benötigt und anschließender Filterung in PHP brauchen wir wohl gar nicht erst reden.

Mir fällt gerade wirklich kein Beispiel ein, dass sich in angemessener Form sowohl über DB als auch über PHP regeln ließe und in dem PHP schneller wäre als SQL.
Aber du darfst mir gerne welche nennen, ich bin selbstverständlich auch nicht allwissend.

Wenn du an bestimmten Stellen in der Umsetzung noch Fragen hast, einfach melden.

Jede Anfrage wird ja ein Datensatz in einer Tabelle `Anfragen` (o.ä.) sein. Die Tabelle kannst du einfach durch ein Tinyint-Feld erweitern in dem du den Status speicherst.
z.B.
0 = offen
1 = in Bearbeitung
2 = geschlossen
Danach dann zu filtern ist ja kein Problem.

Optional kannst du auch noch ein weiteres Feld hinzufügen, in dem du die User-ID desjenigen speicherst, der die Anfrage übernommen hat.
Wenn du noch weiter gehst speicherst du noch den Zeitpunkt an dem er die Anfrage übernimmt und den Zeitpunkt an dem er die Anfrage schließt. Beim schließen der Anfrage kannst du dann auch direkt eine automatisierte Mail an den User schicken der die Anfrage gestellt hat (sofern die Email bekannt ist und das gewünscht ist).

Viele Leute erlauben bei Tabellenfeldern wenn nicht zwingend etwas darin stehen muss auch NULL-Werte.
Wenn man für Felder NULL-Werte erlaubt verlangsamt das aber Abfragen auf diese Tabelle. Deswegen soll lieber ein leerer String oder bei INT-Feldern eine 0 gespeichert werden und die Tabellenfelder als NOT NULL deklariert werden. NULL-Werte sollten nur erlaubt werden wenn sie wirklich nötig sind, wenn es also einen Unterschied zwischen einem leeren String (bzw. einer 0) und einem NULL-Wert gibt.

Edit:
Ich zitiere grad mal noch den entsprechenden Ausschnitt aus dem Buch "High Performance MySQL" (übrigens sehr empfehlenswert, http://www.amazon.de/Performance-Op…88691065&sr=8-2 )

Zitat

[...]
Es ist für MySQL schwieriger, Abfragen zu optimieren, die sich auf Nullable-Spalten beziehen, weil diese die Vergleiche von Indizes, Indexstatistiken und Werten deutlich komplizierter machen. Eine Nullable-Spalte belegt mehr Speicherplatz und erfordert in MySQL eine spezielle Verarbeitung. Wenn eine Nullable-Spalte indiziert wird, braucht sie pro Eintrag ein zusätzliches Byte und kann in MyISAM sogar dafür sorgen, dass ein Index fester Größe (wie etwa der Index einer Single-Integer-Spalte) in einen Index variabler Größe konvertiert wird.
Selbst wenn Sie die Tatsache eines "kein Wert" in einer Tabelle speichern müssen, müssen Sie nicht unbedingt NULL verwenden. Nehmen Sie stattdessen lieber Null, einen speziellen Wert oder einen leeren String.

$(function() {
	$("#selectAll").click(function() {
		if($(this).val()==0) {
			$(this).parents("table")
             .find("input:checkbox")
             .attr("checked","checked")
             .val("1");
		}
		else {
      $(this).parents("table")
             .find("input:checkbox")
             .attr("checked","")
             .val("0");
		}
	});
});

So hab ich sowas umgesetzt, über den value gehen. Funzt einwandfrei.

Ich schließe mich da Pion an, finde ich auch nicht unbedingt nötig. Wikipedia ist für mich ein Nachschlagewerk, kein Lehrbuch. Und als Nachschlagewerk nutze ich für Programmiersprachen grundsätzlich die offiziellen Seiten, da ich mich dort am ehesten auch wirklich auf die Informationen verlassen kann. Und wenn es um allgemeine Fragen zur Programmierung geht suche ich lieber auf einer Seite die sich konkret auf meine Programmiersprache spezialisiert hat.

Das ist aber meine persönlich Meinung, mag gut sein, dass es bei vielen Leuten Anklang finden würde, so es denn gut umgesetzt ist.

Speziell für php kenne ich da als vergleichbare Seite bisher http://www.phpbar.de

Zitat von newmi

hm, sieht an sich gut aus,
Aber ich bekomms nicht hin die procedure zu installieren.

muss wohl noch n bisschen tüfteln.
fehlermeldung ist:

Code

[B]SQL-Befehl:[/B]     
              CREATE  PROCEDURE lib_Explode( sSepar VARCHAR( 255  ) , saVal TEXT ) body :  BEGIN  DROP  TEMPORARY  TABLE  IF  EXISTS lib_Explode;


     
      [B]MySQL meldet: [/B][URL='http://dev.mysql.com/doc/refman/5.0/en/error-returns.html'][IMG]https://h1654076.stratoserver.net:8443/domains/databases/phpMyAdmin/themes/original/img/b_help.png[/IMG][/URL] 
  #1064 - You have an error in your SQL syntax; check the manual that  corresponds to your MySQL server version for the right syntax to use  near '' at line 5

aber danke schonmal. ich glaube dass könnte schon das richtige sein

Die Fehlermeldung klingt so, als ob du vor Anlegen der Stored Procedure den Delimiter nicht geändert hast. Dadurch wird beim ersten ; angenommen die Procedure sei zuende.
Einfach vor der Stored Procedure den Delimiter auf beispielsweise // ändern, die Procedure mit // abschließen, und den Delimiter danach wieder auf ; setzen:

DELIMITER //
CREATE meineProcedure
....
END
//
DELIMITER ;

MySQL rechnet definitiv schneller als PHP, das hast du richtig gehört. Sämtliche Aufgaben die von der DB erledigt werden können sollte man auch ihr überlassen.
Deine Stored Procedures sind so lange aktiv wie du sie nicht wieder löschst (wie auch deine Tabellen). Die müssen nach einem Serverneustart nicht neu angelegt werden.

Für regelmäßige Skript-Aufrufe sind nunmal Cronjobs gedacht. Wieso willst du die nicht nutzen?
Ich wüßte spontan keine Alternative um SQL-Scripts regelmäßig laufen zu lassen, außer den Sachen die du ausschließen möchtest.

Zu den Engines:
In Punkto Transaktionen ist zur Zeit InnoDB am stabilsten und am besten integriert. Bietet auch Row-Level-Locking wenn ein Mix aus Operationen nebenläufig ausgeführt werden muss.
Für Tabellen auf die hauptsächlich SELECTs und INSERTs ausgeführt werden ist MyISAM eine gute Wahl.
Heap (Memory-Engine) sollte nur für Tabellen verwendet werden, deren Inhalte sich nicht ändern (z.B. PLZ-Lookups) oder bei denen es egal ist wenn die Inhalte bei einem Server-Neustart verloren gehen. Die Tabellenstruktur bleibt beim Neustart erhalten, aber die Daten sind weg und müssen danach eben neu eingespielt werden. Heap bietet keine Text-/Blob-Felder und unterstützt nur Zeilen fester Größe. Man muss also beispielsweise statt VARCHAR dann CHAR verwenden, was je nach Inhalten eine gewisse Speicherverschwendung darstellt.
Bevor du dich für eine Engine entscheidest solltest du dir auf jedenfall über die Tabellenstrukturen im Klaren sein und wie diese Tabellen verwendet werden.

Wichtig ist für die Performance auch das vernünftige setzen von Indices, große Tabellen zu partitionieren kann auch viel ausmachen.
Dann halt noch so Kleinigkeiten wie richtige Wahl der Feldtypen, z.B. die SQL-Feldtypen zur Speicherung von Zeit und Datum verwenden, für Strings die immer eine (nahezu) gleiche Länge haben Feldtyp CHAR statt VARCHAR verwenden, keine NULL-Werte erlauben (es sei denn sie werden wirklich explizit benötigt, sonst lieber leeren String oder 0 speichern).
Kann sich auch alles noch läppern.

Dann erstell doch mal ein Script mit nur folgendem Inhalt:

<?php
echo "test";
?>

Bekommst du eine Ausgabe?