• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

MySql Index

X

xXxPeterPanxXx

Neues Mitglied
Hi,
ich will meine Seite noch ein bisschen schneller machen und will deshalb mysql Indexe verwenden. Aber die Tutorials die ich bisher gesehen habe waren mir zu schwer. Also kennt ihr einen Idioten Tutorial?


Und noch eine Frage was ist besser einen doppelt so langen Code aus der Datenbank auszulesen oder einen kurzen Code durch eine Funktion zu jagen die BB Codes umwandelt?

MfG xXxPeterPanxXx
 
Werbung:
threadi schrieb:
Wegen der Code-Frage: ich würde sowas immer versuchen in der Datenbank zu erledigen.
Zum Vergrößern anklicken....

Ich würde die Originaldaten (in diesem Fall also noch ungeparst, mit BB-Code-Tags) in die Datenbank schreiben und erst bei Ausgabe im PHP-Code für die gewünschte Art der Darstellung aufbereiten. So behält man alle Optionen.

(Später kann man immer noch über Caching nachdenken, falls die Rendervorgänge zu viele Ressourcen verbrauchen sollten. Das aber nur der Vollständigkeit halber. Das wird absolut kein Problem werden.)
 
Werbung:
Danke für die Links werde ich mir anschauen.

Zu dem Code:

Also nocheinmal einmal etwas genauer. Ich benutze Geshi Syntax Highlighting für meine Seite, deshalb durchläuft der text mehrere Funktionen, nun weiß ich nich ob dabei viel zeit verloren geht und ob es praktischer ist Die Daten schon vor der Datenbank zu Highlighten.

mermshaus: Ich hatte gedacht das ich zwei Tabellen anlege einmal mit BB Codes und einmal mit gehlighten Code.

Was ist nun besser?

MfG xXxPeterPanxXx
 
xXxPeterPanxXx schrieb:
mermshaus: Ich hatte gedacht das ich zwei Tabellen anlege einmal mit BB Codes und einmal mit gehlighten Code.

Was ist nun besser?
Zum Vergrößern anklicken....

Das kannst du natürlich machen, ich halte es ohne konkreten Anlass aber für unnötig. Wir sprechen hier von maximal ein paar Millisekunden, um die das BBCode-Parsing/GeSHi-Highlighting bei jedem Request die Rechenzeit verlängert. Das wäre für mich erstmal Optimierung am falschen Ende.

Im Zweifel einfach mal messen, wie lange der entsprechende Code-Abschnitt im Vergleich braucht:

PHP: 
$start = microtime(true);

deineFunktion();

echo 'Took ' . ceil((microtime(true) - $start) * 1000) . ' milliseconds';

Caching-Mechanismen (nicht anderes wäre für mich die zweite Tabelle) kannst du bei Bedarf aber auch nachträglich immer noch einbauen. (Dann würde ich aber überlegen, noch "weiter oben" anzusetzen und den kompletten generierten HTML-Code für eine URL zu cachen.)
 
Werbung:
Ich verstehe die Frage nicht.

Aber zum Absatz, den du zitierst: Du erzeugst ja für jede nachgefragte URL eine HTML-Seite. Der Code dieser Seiten ändert sich vielleicht für viele URLs nur selten (oder gar nicht), müsste also nicht ständig neu durch PHP erzeugt werden. Du könntest ihn einmal erstellen und dann irgendwo zwischenspeichern und in Zukunft von dort laden. Das ist mit Caching gemeint.
 
Ja und ich meinte das ich noch vor dem INSERT den Code erstelle, sprich Syntax Highlighting und BB Codes und dann kann ich ihn so ausgeben und setzte den Index nur auf die ID oder auf den Namen.

MfG xXxPeterPanxXx
 
Das haben wir doch schon diskutiert. :) Ja, das könntest du so machen, aber ich halte es generell für eine gute Idee, die Originaldaten zu speichern.

Eine etwas bemühte Analogie: Die Originaldaten sind der Quellcode, das ausgabefertige HTML ist das kompilierte Programm. Nun könnten nachträglich Fehler im kompilierten Programm auftauchen oder es soll für ein anderes System kompiliert werden. In beiden Fällen wäre es ärgerlich, wenn der Quellcode weg wäre.

Zum Beispiel könntest du irgendwann die Notwendigkeit verspüren, bei deinem BBCode-Parser einzutragen, dass erzeugte URLs ein automatisches title-Attribut gesetzt bekommen oder ähnliches. Irgendwas, woran du vorher nicht gedacht hattest. Andere GeSHi-Einstellungen vielleicht.

Oder du möchtest deine Inhalte als PDF ausgeben oder als Teil eines RSS-Feeds und brauchst dafür ein anderes Markup als für die Ausgabe auf der HTML-Seite.

Sowas solltest du zumindest mit bedenken.

Noch mal kurz zum Caching:

Die gecachte Seite zu einer URL kannst du anhand der URL identifizieren. Die könntest du etwa als Spalte mit in die Datenbank setzen, wenn du die gecachten Daten in eine Tabelle schreiben willst. Aber wie schon gesagt: Das sind alles nur Denkanstöße. Du kannst auch "bloß" den in HTML umgeformten BB-Code cachen und nicht das HTML-Gerüst drumrum. Oder nicht einmal den. ;)
 
Werbung:
So ich mache es jetzt mit zwei Tabellen so dass Anderungen noch möglich sind und setze den Index auf den Namen.

Entschuldigung das ich nicht alles so schnell begreife.:oops:

Danke mermshaus

MfG xXxPeterPanxXx
 
Doppelpost!
;)

Mir ist bekannt was Index und Fulltext ist über Primary weiß ich nur "jede Tabelle sollten einen haben" und über Unique habe ich gelesen das man damit eine Spalte beschreibt.

Stimmt das über Primary und Unique?

MfG xXxPeterPanxXx
 
Ja, im Prinzip schon. Jede Tabelle, die Datensätze enthält, sollte einen Primary Key mit Auto Increment haben. Der übliche Name für das entsprechende Feld ist "id". Die id eines Datensatzes sollte der einzige Wert sein, über den er in anderen Tabellen referenziert bzw. insgesamt identifiziert wird.

"Unique" besagt grob, dass in einer Spalte kein Wert doppelt auftreten darf.

Sehr grobe Faustregel für Indizes: Jede Spalte, die bei Abfragen in einer WHERE-Klausel auftaucht, sollte einen Index besitzen. Ausnahmen bestätigen die Regel.

Vielleicht schaust du mal in ein Tutorial rein.

Peter Kropff - MySQL - Einleitung
 
Werbung:
So ich sage mal wie ich jetzt die Indexe setzten würde:

Das ist meine Tabelle:
Code: 
CREATE TABLE `eintraege` (
  `id` int(7) NOT NULL auto_increment,
  `hits` int(10) NOT NULL,
  `name` varchar(120) collate latin1_german2_ci NOT NULL,
  `nameurl` varchar(120) collate latin1_german2_ci NOT NULL,
  `kategorie` int(7) NOT NULL,
  `tutorial` text collate latin1_german2_ci NOT NULL,
  `code` mediumtext collate latin1_german2_ci NOT NULL,
  `time` int(10) unsigned NOT NULL,
  `description` text collate latin1_german2_ci NOT NULL,
  PRIMARY KEY  (`id`),
  FULLTEXT KEY `name` (`name`,`tutorial`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=82 ;

Alle Felder haben einen anderen Inhalt, darum würde ich jedem Feld Unique zuweisen.

Id würde ich Primary geben.

Und da ich meistens Abfragen mit nameurl mache (WHERE nameurl = blablabla) würde ich den Index auf nameurl machen.


Richtig?

MfG xXxPeterPanxXx
 
Hm, das ist alles etwas schwierig zu erklären.

Unter Vorbehalt, da ich nicht weiß, was deine Felder inhaltlich genau bedeuten:

id - PRIMARY KEY, klar
nameurl - UNIQUE

Sonst nichts an Indizes (außer dem FULLTEXT-Zeugs, das wäre dann für Suche -- fällt mir gerade nichts zu ein, bin auf dem Sprung). Es ist der Datenbank egal, dass es nicht besonders viel Sinn macht, inhaltlich zweimal dasselbe Tutorial zu schreiben. Wichtig ist nur, dass die strukturellen "Meta"-Informationen eindeutig und konsistent sind. Für die Software heißt es lediglich: "Das ist Datensatz mit ID 1. Das ist Datensatz mit ID 2." Damit sind die beiden Einträge unterschieden. Was nun tatsächlich für inhaltliche Daten drinstehen, ist völlig gleichgültig.

Code: 
  `time` int(10) unsigned NOT NULL,

Es gibt einen Datentyp DATETIME, den solltest du nehmen.
 
Werbung:
nach meiner auffassung und erfahrung ist es keine option, ausführbaren text (code) in einer datenbank abzulegen. sowas wird schon vernünftiger weise per bbcode funktion gelöst.


  1. text, der als html-formatierter text abgelegt wird mutiert zu code, der ausgeführt wird (eine katastrophe!)
  2. jeder kann die ausgabe so anpassen, wie er möchte, feste style einstellungen würden bei einer änderung der formatierungen der anzeige immernoch in der gespeicherten version angezeigt
  3. nicht jeder hat die selben sicherheits einstellungen. man hebelt u.u. sicherheitseinstellungen aus (schlagwort backup und einspielen in eine andere datenbank, anderen hoster)
für mich steht ausser frage, das läuft IMMER durch eine funktion.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben