|
|
|
|
It was hard...but \I
Der ist mir gerade eingefallen
|
|
|
|
|
|
|
aha?
|
|
|
|
|
|
|
| Zitat von Achsel-des-Bösen
It was hard...but \I
Der ist mir gerade eingefallen
| |
aem??
|
|
|
|
|
|
|
Wollt ihr mir irgendwas mitteilen?
|
|
|
|
|
|
|
Also mir erschliest sich ja der Gag irgendwie nicht so ganz...
|
|
|
|
|
|
|
It was hard...
Spoiler - markieren, um zu lesen:
...but I escaped
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 23.08.2007 14:37]
|
|
|
|
|
|
Achso...jetzatle!
|
|
|
|
|
|
|
ich dachte schon ich wär der einzige
|
|
|
|
|
|
|
entschuldigt die ketzerische frage, aber hat schonmal jemand von euch mit pdo (php ) gearbeitet? Ist das ganze sinnig? Ist ja erst seit php5.1 dabei
|
|
|
|
|
|
|
| Zitat von kinglui69
entschuldigt die ketzerische frage, aber hat schonmal jemand von euch mit pdo (php ) gearbeitet? Ist das ganze sinnig? Ist ja erst seit php5.1 dabei
| |
Ich hab schon vor 1 bis 2 Jahren damit gearbeitet. Es ist sinnig und wenn du es erst jetzt entdeckt hast, bsit du ganzschön doof
|
|
|
|
|
|
|
| Zitat von kinglui69
entschuldigt die ketzerische frage, aber hat schonmal jemand von euch mit pdo (php ) gearbeitet? Ist das ganze sinnig? Ist ja erst seit php5.1 dabei
| |
Ja, sowas ist gut
Und auch ein Punkt wo ich bei PHP jedesmal die kretze kriege...jeder implementiert seine eigene Datenbankklasse mit vermeidlicher Abstraktion...
|
|
|
|
|
|
|
| Zitat von GH@NDI
| Zitat von kinglui69
entschuldigt die ketzerische frage, aber hat schonmal jemand von euch mit pdo (php ) gearbeitet? Ist das ganze sinnig? Ist ja erst seit php5.1 dabei
| |
jeder implementiert seine eigene Datenbankklasse mit vermeidlicher Abstraktion...
| |
heey
|
|
|
|
|
|
|
Ja tut mir leid
Aber das ist einfach falsch.
Zumindest solange man sich wirklich um die Abstraktion kümmert um später unabhängig vom RDBMS sein kann. Eine art kleines ORM bzw. eine eigenen Schnittstelle über die man per getUserInfo($userid) bequem Informationen vom User querien kann sind nicht verwerflich sondern förderlicher...ich hab auch schon code gesehen (und früher z.T. auch selbst geschrieben) bei dem mitten in der Programmlogik dann ein SQL Query auftaucht...und irgendwann steht 5mal das selbe Query an verschiedenen Stellen. Dann fällt einem auf, man braucht eigentlich noch ne Spalte in der Tabelle oder sollte was umbenennen...und schwupp ist alles dahin...man ändert 5 Queries ab und ruck zuck haben sich irgendwelche Fehler eingeschlichen die dann irgendwann ein böser SQL-Injector für sich ausnutzt
|
|
|
|
|
|
|
ich guck mir das jetzt mal an
|
|
|
|
|
|
|
argh, regex ist des Todes
folgender regex macht aus links anklickbare links.
|
Code: |
$message = preg_replace('#(^|[^\"=]{1})(http://|ftp://|mailto:|news:|www.)([^\s<>]+)([\s\n<>]|$)#sm',
"\\1[url=\\2\\3\]\\2\\3[/url]\\4",$message); |
|
Leider macht sie das auch bei
|
Code: |
[img]http://www.blubb.de/bild.jpg[/img] |
|
Ich komm aber auch nicht auf die Idee wie ich da ein "außer bei [img][/img] " rein bekomme
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von Ashtray am 23.08.2007 15:43]
|
|
|
|
|
|
Ich hab enormen Nachholbedarf, was Datenbanken angeht. Ich kann sie ja auswerten, in sie schreiben etc. pp. - aber ich bin einfach zu blöd, eine ordentliche Tabellenstruktur reinzubringen. Ich schreibe alles in eine Tabelle, obwohl ich das trennen will.
Beispiel:
Ich hab die ID3-Taggings einer mp3, den Pfad, sowie die Länge in einer einzigen Tabelle. Obwohl ich gerne ID3-Taggings und den Rest getrennt haben möchte. Dazu müsste ich doch einfach zwei Tabellen erstellen und zwischen den beiden id-Spalten eineBeziehung erstellen, oder? id ist integer, primary und auto-increment.
|
|
|
|
|
|
|
das könnte man auch noch ganz anders aufteilen. Die ID3-Tags sind Metainformationen zu den MP3s. In einem Album ändert sich an den Metadaten jedes Stücks ja eigentlich nur die Nummer und der Titel. Ich würd sowas in mehreren Tabellen unterbringen:
Tabelle Artists - enthält die Daten zum Künstler oder Anbieter (bei Samplern)
Tabelle Albums - enthält die Daten zum Album (Erschienen am, Genre...)
Tabelle Songs - enthält die Daten zum Song, inkl. Pfad zur MP3
alternativ kann man für die Dateien noch eine eigene Tabelle bauen und die dann mit der Songs-Tabelle verknüpfen.
|
|
|
|
|
|
|
Skunky:
Kann man sich drüber streiten. Es noch nicht mal falsch die ID3 Daten in eine Tabelle mit den Dateinamen und Pfaden zu schreiben, denn es handelt sich hier um eine 1:1 Beziehung. Ein Tag kann nur zu einer Datei gehören und eine Datei hat nur einen Tag.
Da ein ID3 Tag ansich aber etwas abgeschlossenes ist, das nur an eine Musik-Datei angehängt wird, kann man auch ohne weiteres rechtfertigen es auszugliedern. Bzw. diese Tabelle allgemeiner zu halten => Tags, und noch verschiedene Tag-Typen zu spezifizeren (ID3v1, ID3v2, XIPH-Comment, etc). Wobei man da schon wieder aufpassen müsste weil ja nicht jeder Tag-Art die gleiche Menge und Art von Feldern hat, manche Tag-Art sogar völlig frei in der Gestaltung ist.
/e: Und letztenendes ist eine Aufteilung wie sie Garland vorgeschlagen hat noch viel sinnvoller.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SirSiggi am 23.08.2007 15:46]
|
|
|
|
|
|
void(0)
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 23.08.2007 16:50]
|
|
|
|
|
|
Amtliche UNWETTERWARNUNG vor SCHWEREM GEWITTER mit HEFTIGEM STARKREGEN
für die Stadt Wolfsburg
Weiterhin Gewitter mit Starkregen von 30 bis 50 Liter pro
Quadratmetern in kurzer Zeit sowie örtlich Hagel und Sturmböen
Stärke 8 bis 75 km/h um Ost.
\o/
|
|
|
|
|
|
|
| Zitat von GarlandGreene
das könnte man auch noch ganz anders aufteilen. Die ID3-Tags sind Metainformationen zu den MP3s. In einem Album ändert sich an den Metadaten jedes Stücks ja eigentlich nur die Nummer und der Titel. Ich würd sowas in mehreren Tabellen unterbringen:
Tabelle Artists - enthält die Daten zum Künstler oder Anbieter (bei Samplern)
Tabelle Albums - enthält die Daten zum Album (Erschienen am, Genre...)
Tabelle Songs - enthält die Daten zum Song, inkl. Pfad zur MP3
alternativ kann man für die Dateien noch eine eigene Tabelle bauen und die dann mit der Songs-Tabelle verknüpfen.
| |
Vielleicht sollte man die Zuordnung von Song und Album/Sampler noch mal seperat machen, da ja ein Song auf mehreren Alben drauf sein kann. Da dies aber im ID3-Tag nicht vorgesehen ist, hätte man sich da ne schöne Insel-Lösung gebaut, die nur mit der eigenen Datenbank läuft. Sinnvoll finde ich es trotzdem
|
|
|
|
|
|
|
Hier in Bitz ist, und bleibt laut DWD auch, das Wetter bestens
|
|
|
|
|
|
|
void(0)
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 23.08.2007 16:50]
|
|
|
|
|
|
Halte ich für IHK Gerecht verteilt.
/e: Im schlimmsten Fall melden sie sich bei dir und möchten das ganze nochmal ausführlicher haben. Aber ich denke das passt so.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SirSiggi am 23.08.2007 16:29]
|
|
|
|
|
|
Hier stand nie etwas! Echt net!
|
|
|
|
|
|
|
| Zitat von Achsel-des-Bösen
Hier stand nie etwas! Echt net!
| |
|
Code: |
select * from posts p where p.pid = 1238110838 or p.pid = 1238110701 |
|
|
|
|
|
|
|
|
Mir ist nur aufgefallen, dass ich ein paar Sachen da drin stehen ab, die so nicht in die finale Fassunf sollen und ich will ja nicht, dass die IHK wohlmöglich mittels Google die ursprüngliche Fassung zu gesicht bekommt
|
|
|
|
|
|
|
Was machst du eigentlich? So eine Art Lehrabschlussprüfung?
|
|
|
|
|
|
|
Als es den SQL Dump immernoch als .gz file gab, konnte man auch immer noch nach den posts im Gehirnsalat suchen
Wundert mich ja irgendwie, das Google ein 2mb großes .gz file saugt und dann die darin enthaltene 9mb große SQL-Datei indiziert
|
|
|
|
|
|
|
Schreib in einer Textdatei eine 0 und zwölf Billiarden 1, pack sie und warte bis der Googlebot sie auspacken will
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 23.08.2007 17:18]
|
|
|
|
|
Thema: Gehirnsalat ( wir unter uns ) |