Quote

Das Datenbanklayout sieht nicht wirklich durchdacht aus. Einerseits hast Du recht mit der Konvertierung der Daten, aber auf der anderen Seite: wozu den Zwang ein Board nach einem bestehenden DB-Layout zu coden? Ich würde an dieser Stelle erstmal ein neues, besseres Layout erstellen, das auch die Tatsache der Erweiterbarkeit berücksichtigt. ein Konverter von der jetzigen DB zu einer neuen ist dafür schnell geschrieben, meiner Meinung nach.

Du triffst den Nagel auf den Kopf, das ist ganz meine Meinung!

Strat, das Datenbank Design sollte dringendend überarbeitet werden. z.B. Die Abfragegeschwindigkeit könnte drastisch gesteigert werden, wenn auf varchar verzichtet wird. Char kostet zwar mehr Festplattenspeicher läuft aber wesentlich schneller.\n\n

<!--EDIT|jan10001|1061756090-->

vorschlag: einfach mal eine analyse des aktuellen datenmodelles machen:
was passt an der tabellenaufteilung gut und was nicht?
Ob eine Spalte varchar oder char ist, ist eigentlich recht egal, weil man das recht schnell an unsere zwecke anpassen kann.

Mir gefaellt die Verwendung einer Spalte fuer die ganzen Nachrichten, weil es die Verwaltung und die Suche sehr vereinfacht. Als Idee koennte man vielleicht die Nachrichten, die aelter als ein Jahr sind, in eine weitere Tabelle auslagern, weil man die wohl nur selten durchsuchen duerfte. Ich kann aber noch nicht abschaetzen, wieviel das wirklich bringt.

Als Minimum von Tabellen brauchen wir mal folgende:
x) Active_Sessions
x) Categories
x) Forums
x) Posts
x) Post_Titles (wohl besser in Posts integrieren; macht die Verwaltung einfacher)
x) Usergruppen
x) User
x) Userprofiles

Relationen:
Categories <=> Forums 1:n
Forums <=> Threads 1:n
Threads <=> Posts 1:n
Posts <=> User n:1
User <=> Userprofiles 1:1
User <=> Usergruppen n:1

Dabei ist da noch die Moderation noch nicht drinnen.

Folgende Sachen wuerde ich als Templates realisieren:
Email
Hilfe

nein ich meinte mod_rewrite ...
in .htaccess steht nicht nur die verlinkung zu .htpasswd (oder wie das heißt drin) sondern auch anders zeugs!

[quote=kabel,25.08.2003, 19:58]wie wärs mit einem apache-ähnlichem callback design?[/quote]
das ist auch einer meiner Gruende, es mit mod_perl und Apache::Registry zu machen

@esskar: sieht gut aus, und mit \& schreibt sich eine Subreferenz einfach besser :-))

Ich habe nochmal Marky's Argumente in dem anderen Thread ueberschlafen und mal kurz die Doku zu Apache::PerlRun ueberflogen. Da kommt man zwar anscheinend nicht an so viel vom Apache dran, aber es ist halt viel einfacher zu coden...
Die Vorteile gegenüber CGI waeren die folgenden:
1. Man koennte Module vorladen (z.B. CGI, DBI)
2. Geschwindigkeitsvorteil 2-3x
3. Man kann so Coden, wie man es von CGI her gewohnt ist (wenn das CGI sauber ist).

Der Eintrag in der httpd.conf koennte folgendermaszen aussehen:

Damit wuerde die Entwicklung auf jedem Fall einfacher.

@esskar: was denkst du darueber? Besser oder schlechter?

k...
sollen wir dann mal starten?
könntest dann ja mal vielleicht eine subdomain einrichten...

develop.perl-community.de

oder so und mir die daten zu schicken...

hmmm...

Wollt ihr eine strikte Trennung zwischen cgi-bin und non-bin ?
also ich mach es immer so, dass ich meine scripte nicht in cgi-bin legen muss, um sie auszuführen... dadurch kann ich relative auf files zu greifen und muss das nicht absolute tun!

ich hab mal versucht, mein bisher programmiertes zeug auf den server zu legen und aus zuführen...
er meint aber immer, dass ich "Premature end of script headers".. print "Content-Type: text/html\n\n"; gebe ich aber aus...

kann das mal jemand checken? Habe meine Sachen wieder runtergeworfen aber in /html/cgi-bin/ liegen env.pl und env.cgi

http://develop.perl-community.de/cgi-bin/env.pl
http://develop.perl-community.de/cgi-bin/env.cgi

[quote=esskar,27.08.2003, 02:38]kann das mal jemand checken? [/quote]
und wie?

[quote=Strat,27.08.2003, 11:09]

und jetzt geht's![/quote]
man... ist linux pingelisch!!!

wie wär's mit einem killfile? ;)