Benutzer:NBarchiv/Neuanfang

diese seite soll der entwicklung einer neuen db-anwendung dienen...

na, dann... Reinhard

Tabellenstruktur (neu; Reinhard)

Tabelle Mentor

MentorID        - Long (Identity, Primary Key)
MentorName      - Text(50)
MentorKommentar - Text(255) 
MentorStatus    - Text(1) 
...

Tabelle Mentee

MenteeID        - Long (Identity, Primary Key)
MenteeName      - Text(50)
MenteeKommentar - Text(255) 
MenteeStatus    - Text(1) 
...

Tabelle Betreuung

MentorID        - Long (Foreign Key --> Tabelle Mentor) \  
MenteeID        - Long (Foreign Key --> Tabelle Mentee)  > (Primary Key)
BetreuungBeginn - Date                                  /
BetreuungEnde   - Date
BetreuungKommentar - Text(255) 
BewertungID     - Long (Foreign Key --> Tabelle Bewertung)
...

Tabelle Bewertung

BewertungID     - Long (Primary Key)
Bewertung       - Text(50)
...

Tabelle Status

Status          - Text(1)
Bezeichnung     - Text(50)
...

Tabelle Artikel

Lemma           - Text(255) (Primary Key)
MenteeID        - Long (Foreign Key --> Tabelle Mentee)
ArtikelKommentar - Text(255) 
PageID          - Long
...

WOW! (alt: Ulli Purwin)

...da bleibt mir natürlich nur noch, den ersten schritt nachzuholen:

bestandsaufnahme

derzeit gibt es lediglich zwei tabellen:

• tabelle "wp_neulinge"
• tabelle "wp_mentoren"

1.) wp_neulinge:

• wp_neulinge_ID
• wp_mentoren_ID
• neulinge_Name
• SUCHNAME
• neulinge_status
• neulinge_in
• neulinge_out
• neulinge_bemerkung
• erster_artikel
• artikel_gesamt
• LastUpdate

2.) wp_mentoren:

• wp_mentoren_ID
• wp_scrollbox_ID
• wp_scrollbox_text
• mentoren_Name
• mentoren_un
• mentoren_pw
• mentoren_status
• mentoren_in
• mentoren_out
• mentoren_bemerkung
• neulinge_gesamt
• sprachen

(*auszeichnungen) (*LastUpdate)

...in arbeit/geplant:

3.) wp_artikel:

• wp_artikel_ID
• wp_neulinge_ID
• wp_mentoren_ID
• artikel_titel
• artikel_bemerkung
• artikel_bereich
• LastUpdate

im wesentlichen stimmen die feldbeschreibungen überein. müsste ich noch genauer darstellen... bei einer eventuellen altdaten-übernahme wäre lediglich zu berücksichtigen, daß die 'datümer' bei mir (mit ausnahme von 'wp_neulinge.LastUpdate' kein datumsformat haben, sondern long integers sind (yyyymmdd) wg. der leichteren differenz-rechnungen in der statistik. besonders das propietäre Access iss dafür anfällig, datümer anders zu interpretieren... ;) !

bis jetzt hat die beschränkung auf nur zwei tabellen noch keine nachteile gezeigt: 'scriptmässig' isses natürlich wesentlich einfacher zu händeln: zuviele tabellen zwingen eigentlich nur zu überflüssigen inner/outer joins nach dem schema "select * from tabelle1 A, tabelle2 B, tabelle3 C etc."...

der wichtigste grundgedanke beim ganzen war die 'zweier-beziehung': kein mentor ohne mentee - kein mentee ohne mentor! dies zwang vor allem auch die neu-mentoren zur raschen aufnahme eines mentees, um überhaupt in der DB zu erscheinen ;) ...

notwendig und sinnvoll wäre in jedem fall die aufnahme einer dritten tabelle:

wp_artikel - das hatte ich schon seit längerem geplant. hierbei wäre der wichtigste aspekt, herauszufinden, inwieweit uns eine bot-anwendung(~escaladix) behilflich sein könnte... es wird immer schwerer, den stand nachzuhalten - ...dauert nich mehr lange, und es iss unmöglich...

...tip von sebmol: Benutzer:Head fragen. den treff ich hoffentlich demnächst auch mal auf einem Aachen-Stammtisch zusammen mit Euku, der ihn auch gut kennt...

Na ja, das Access-Datum ist ein Double, eigentlich kann man damit genauso gut rechnen wie mit einem Long... Die 1:n-Beziehung zwischen Mentoren und Mentees erweist sich ja wohl schon jetzt als Nachteil, da es Mehrfachbetreuungen und zeitweise verwaiste Mentees gibt. "Zu viele Tabellen" kann es m.E. nicht geben - wenn die reale Situation eine n:m-Beziehung ist, tut man sich keinen Gefallen, sie auf eine 1:n-Beziehung zu reduzieren. Was die Artikel angeht, kann man die doch auch wunderbar über die API ermitteln: http://de.wiki.x.io/w/api.php?action=query&list=usercontribs&ucuser=Ahim1947&uclimit=max&ucprop=title%7Ctimestamp%7Cids%7Cflags --Reinhard Kraasch 10:16, 16. Jan. 2009 (CET)

tabellenzahl

...ok, ich laß mich gern vom gegenteil überzeugen. da wird aber wiegesagt die SQL-struktur komplizierter...

Na, dafür sind wir doch Profis ;-) --Reinhard Kraasch 17:58, 16. Jan. 2009 (CET)

datumsformate

• Long: 'yyyymmdd' (geeignet, wenn es nicht auf die uhrzeiten ankommt)
• Double: 'yyyymmddHHMM' (mit uhrzeiten. Access macht zwar eine dezimalzahl draus, aber das '.0' am ende lässt sich ausblenden)

mit beiden lässt sich prima rechnen; zeitl. reihenfolge ist automatisch garantiert.

anders beim

• DateFormat: {ts yyyy-dd-mm HH:MM:SS} (auch ODBC-timestamp genannt), welches auch noch länderspezifisch variiert. im englischen sprachraum wird z.b. monat und tag verdreht... diese werte sind ungünstig, wenn man eine bestimmte zeitspanne errechnen will. ist nur bei LastUpdate, EntryDate oder ähnlichen statischen zeitbestimmungen sinnvoll.

Nee, da irrst du dich - Access hat keine Timestamps - und die Access-internen Date-Felder sind wirklich nichts anderes als Doubles (kannst du mir gerne glauben, ich war mal so etwas wie ein Access-Papst ...), allerdings machen die ODBC-Treiber daraus schon manchmal Unfug, das stimmt wiederum schon. Letztendlich muss man immer die richtigen Formatierungs- und Konvertierungsfunktionen verwenden, aber das gilt für Longs natürlich genau so (da überlässt man halt die Konvertierung dem Benutzer, in der Hoffnung, dass er keinen Mist einträgt...) --Reinhard Kraasch 17:55, 16. Jan. 2009 (CET)

artikelzählung

...der obengenannte API-link zeigt ja allesmögliche an. im gegensatz zum tool, welches nur die gestarteten artikel auflistet.

Muss man halt geeignet filtern (da scheint noch ein Bug drinzusein, da der Flag "new" nicht erscheint). Beim derzeitigen Stand muss man das halt gegen die Artikel abgleichen. --Reinhard Kraasch 17:57, 16. Jan. 2009 (CET)

...hier nochmal mein credo für eine Unabhängigkeit von der Artikelgrösse:

ein artikel ist ein artikel - daran werden wir nix ändern.

...die festlegung auf eine 'anerkannte mindestgrösse' ist subjektiv und damit willkürlich.

es gibt genug beispiele dafür, daß auch 'Mini-Artikel' ihre berechtigung haben: sie sollten nur keine redirects sein... gruß, --NB/archiv 00:56, 21. Jan. 2009 (CET)

eventuelle 'altdaten-übernahme'

...ich kann dir die entsprechende .mdb per mail schicken - das hab ich mit Euku auch schon gemacht... es wäre von vorteil, wenn du eine 'test-umgebung' hättest...(?)

... 'test.mdb' ist abgeschickt!

Ja, danke - ich hab sie auch schon in eine mySQL-Datenbank übernommen. --Reinhard Kraasch 17:57, 16. Jan. 2009 (CET)

...hört sich gut an! ich würde evtll. auch die mtl. kosten für eine WAMP-domain (€ 6.99) übernehmen, um das ganze hinterher performant unter php/mysql auf apache laufen zu lassen.

...schau mal auf ->http://purwin.artkatalog.net - da hatte ich das mal ausprobiert, meine CF-seite zu portieren... vorteil bei 'freenet.de': kostenlos weitere 15 subdomains möglich, und 9 wären noch frei...! dieser server hatte in den zweieinhalb jahren keine stunde ausfall.

die neue adresse hiesse dann etwa 'mp.artkatalog.net' und könnte zumindest zum testen benutzt werden...

gruß, --NB/archiv 22:53, 16. Jan. 2009 (CET)

Die Domain hätte ich schon: http://www.dbwiki.de - dort könnte man das als Unterseiten laufen lassen. Derzeit laboriere ich allerdings noch an den PHP-Sicherheitseinstellungen (Safe Mode, allow_url_fopen etc.) herum, die einem alle schönen und einfachen Dinge vermiesen. Die Ausfallzeiten von okayspace halten sich auch in Grenzen (siehe unten auf der Seite). Das kann man aber ja auch immer noch kurzfristig diskutieren bzw. ändern - LAMP- oder auch WAMP-Server gibt es ja zu hauf. --Reinhard Kraasch 11:47, 17. Jan. 2009 (CET)

eine (zum verständnis notwendige) gegenüberstellung beider systeme

...das alte (bisherige) db-system hatte folgende grundlagen bzgl. der artikel:

• schrittweise (additive) ermittlung der artikel-summe in der personen-db per ~escaladix
• dadurch auch nur additive abgleiche nötig - vorausgesetzt, alles stimmte...
• haupt-nachteil: toolserver-probleme, -ausfälle und -beschränkungen
• weiterer nachteil: absolute 'eingabe-abhängigkeit' durch die mentoren
• fraglich war auch die ständige weiterrechnung noch nach der betreuung

...das neue (geplante) db-system

• sofortige ermittlung des datenbestandes via API möglich (wenn der bugfix durch iss)
• haupt-vorteil: weniger aufwand für mentoren (genauer 'workflow' ?)
• beschränkung auf die betreuungszeit + weitere infos enthalten
• muss nur noch irgendwie automatisch in die tabelle übertragen werden...

...ich bitte um ergänzungen/reverts/vorschläge/kompromisse/statements/beschimpfungen usw. --NB/archiv 15:52, 23. Jan. 2009 (CET)

Ich stell mir schon vor, dass die Artikeldaten in der MP-Datenbank gehalten werden und nur bei Bedarf über diesen API-Mechanismus ergänzt werden (also z.B. für Mentees, deren Betreuung zu Ende ist, jeweils einmal und dann nie wieder). --Reinhard Kraasch 22:13, 28. Jan. 2009 (CET)

...ja, genau. sonst ginge das ja bis in alle ewigkeit weiter - iss jetzt schon kaum noch upzudaten. ich hab mir zwar immer gesagt: 'naja, wenn die mentees nach der betreuung fleissig weiterschreiben, isses ja möglicherweise auch eben deshalb ;) ...' aber das artet irgendwann aus. natürlich könnte es 'schocken' wenn die bereinigte gesamtzahl demnächst wesentlich geringer ausfällt - aber auch dies wäre nur einmal und nie wieder :)) ! gruß, --NB/archiv 23:19, 28. Jan. 2009 (CET)

sonstiges

...p.s.: haste eigentlich mal versucht, <h1>Botanik</h1> durch ein entsprechendes image zu ersetzen? dann wäre die störende werbung unsichtbar... (ich meine sowas hier: [1] ... gruß, --NB/archiv 05:26, 16. Jan. 2009 (CET)

Na ja, das Botanik-Teil ist eine reine Demo, die wird so nicht online gehen. (Bei mir wird die Werbung eh vom Popup-Blocker ausgeblendet, ausserdem kleben die ihre Werbung immer irgendwo hin, siehe z.B. www33.websamba.com/botanik/Test.asp) --Reinhard Kraasch 09:10, 16. Jan. 2009 (CET)

vorschlag für die WP-NB

...das war ja mal in der überlegung... ich halte den 'mehraufwand', die nummerntabelle manuell anzupassen, für sowohl erträglich(zur not mach ich das dann immer selbst - können alle anderen von mir aus ignorieren!) als auch für sinnvoll. denn für das PAGESINCATECORY-problem scheint keine lösung in greifbarer nähe zu sein - im gegenteil: die bug-meldungen häufen sich und es herrscht allgemeine ratlosigkeit...

Nr. 1. 2. 3. 4. 5. 6. 7.

Eintritt Mentee Mentor Status 21.07.08 Langhoop Ralf Roletschek Beiträge 25.07.08 Suedlicht M.L Beiträge 27.07.08 Agip Hannes Röst Beiträge 29.07.08 Kleinstein95 Leithian Beiträge 31.07.08 Kleines214 Complex Beiträge 06.08.08 Fouk Redlinux Beiträge

Erste Tests (Reinhard)

Allgemeines + Diskussion

So, ich hab jetzt mal die Altdaten in eine mySQL-Datenbank auf meinem Server hochgeladen und einen ersten Test in PHP geschrieben ([2] wer sich für den Code interessiert: [3]). Damit werden die von den Mentees erzeugten Artikel per API ausgelesen. Da man in die Versionsgeschichte einsteigen muss, um zu ermitteln, ob die Änderung eine Neuerstellung war, ist die Angelegenheit relativ lahm. Ich hoffe aber, dass der entsprechende Bug in der API demnächst behoben wird, dann dürfte es um einiges schneller gehen. --Reinhard Kraasch 22:38, 18. Jan. 2009 (CET)

Super. :-) Könntest du noch die Artikelanzahl des Mentees sowie die Summe aller Artikel ergänzen? Außerdem wäre eine Nummerierung der Mentees nicht schlecht. Gruß,--Tilla 2501 — Wird 2009 das Millionenjahr? 23:06, 18. Jan. 2009 (CET)

...ja, das iss schon klasse, die artikel gesammelt auf betreute mentees zu zeigen - entspricht genau dem grundgedanken, ein ergebnis der betreuung zu zeigen. im gegensatz zu Tilla ;) trau ich mich da ja garnichmehr, noch dreiste sonderwünsche zu äussern! aber im ernst: müsste man nicht auch den (sehr häufigen) fall berücksichtigen, daß ein mentee einen artikel reinstellt (z.b. als unvollständigen stub, oder sogar später mit LA/SLA versehen), und dann damit erst ins MP kommt? die erscheinen dann ja nicht bei angekreuztem 'während der betreuung entstanden' und machen oft doch die meiste arbeit aus... nur so ein beispiel: Krickelberg

vorschlag: ausfiltern könnte man vielleicht nur die artikel nach der betreuung - und bei den vorherigen (zu 99% ist das immer nur einer, nämlich wie oben beschrieben) davon ausgehen, daß es sich um neulinge handelt, die dann auch dabei betreut wurden... gruß, --NB/archiv 14:02, 20. Jan. 2009 (CET)

Ja, da kann man sicher vieles machen, und ich habe auch einiges auf der Liste: Ausfiltern von Redirects, Miniartikeln usw., interessant wären natürlich auch die gelöschten Artikel (ich hab allerdings keine derzeit Ahnung, wie ich an die herankomme - dafür müsste die Anwendung dann wohl doch auf dem Toolserver liegen und direkt auf die Wikipedia-Datenbank zugreifen). Aber bislang war das ja nur eine Fingerübung, die die prinzipielle Machbarkeit (die Portierung der Mentoren-DB-Tabellen in mySQL einerseits und den Zugriff auf die Wikipedia-API und das Parsen der von der API abgesonderten XML andererseits) aufzeigen sollte - und so ganz nebenbei gesagt meine erste ernsthafte PHP-Anwendung ;-) Insofern möchte ich also noch um ein bisschen Geduld bitten. --Reinhard Kraasch 19:49, 20. Jan. 2009 (CET)

... :))) alle zeit der welt, lieber Reinhard - niemand will dich drängeln!! sieht jetzt schon wesentlich vielversprechender aus, als meine (zugegeben) eher laienhaften ansätze...

das direkte angehen der API scheint der schlüssel zu sein - und dein php-stand ist doch auch kein 'anfänger-level' ;) ! ich gliedere das hier nochmal - hoffentlich mit deinem einverständnis - sonst reverten bzw. selbst ergänzen! gruß, --NB/archiv 20:12, 20. Jan. 2009 (CET)

...hab in meinem ganzen edv-leben noch nie so schnell sog. 'to-do's abhaken können wie jetzt! Reinhard iss ein wahres MONSTER!!!

...und jetzt trau ich mich auch zur kritik: es funzt leider nich bei den 'worst cases' - schlimmstes beispiel: Tilla! der hat nun mal über hundert mentees gehabt, und ich glaub nich dran, dasses durch irgendeinen API-bugfix schneller wird: bei dem allein dauert es über 10 minuten... es gibt aber 88 zu berücksichtigende mentoren...

...egal!! das ist schonmal eine erleichterung, wenn man das ganze nur zur ermittlung der gesamtartikel benutzt... 88 mal abgefragt iss immer noch weniger als 1322 mal abgefragt !! --NB/archiv 02:45, 21. Jan. 2009 (CET)

Doch, glaub mir, das hängt an dem API-Bug (er ist schon behoben, aber die entsprechende MediaWiki-Version ist noch nicht freigeschaltet), das müssen wir einfach abwarten. Derzeit muss ich nämlich zu jedem von dem Mentee angefassten Artikel schauen, wer ihn angelegt hat, wenn der Bug behoben ist, kann ich das direkt der Artikelliste entnehmen. Langfristig sollen die Artikel aber ja auch in der Mentoren-Datenbank landen, d.h. ich frage dann nur jeweils die Artikel ab, die dort noch nicht drinstehen, das dürfte auch einiges an Geschwindigkeit bringen. Das beispielsweise bei Tilla nicht alle Mentees angezeigt wurden, war ein Fehler, den ich hoffentlich behoben habe (ich bekomme jedenfalls 114 Mentees angezeigt). Artikelanzahlen und -summe werden jetzt auch ausgegeben. Zusätzlich: Editcount des Benutzers, die Tatsache, dass der Benutzer zwischenzeitlich gesperrt wurde (leider gar nicht so selten!) sowie die Zeichenzahl des jeweiligen Artikels. --Reinhard Kraasch 16:56, 21. Jan. 2009 (CET)

Ich habe jedoch bisher 115 Mentees betreut. Gruß,--Tilla 2501 — Wird 2009 das Millionenjahr? 19:55, 21. Jan. 2009 (CET)

...das hat damit zu tun, daß der db-stand sich nach dem kopieren wieder geändert hatte: Benutzer:Mykarn kam später dazu. iss ja nur ne test-db. gruß, --NB/archiv 21:55, 21. Jan. 2009 (CET)

Zählung der Mentee-artikel

derzeitiger stand der entwicklung: hier (alter stand: dort)

weitere vorschläge dazu: (Tilla, Ulli, Reinhard)

• Nummerierung der Mentees eines Mentors erledigt
• Summe der Artikel der (jeweiligen) Mentees erledigt
• Summe aller Artikel eines Mentees erledigt
• Zählung ab 'Erst-Artikel' (bis Betreuungsende) erledigt
• ohne Redirects erledigt
• keine Mini-Artikel (derzeitige voreinstellung: 100) erledigt

(Eigentlich sind nur Redirects und Subsubstubs unter dieser Größe vorstellbar...) --Reinhard Kraasch 23:19, 21. Jan. 2009 (CET)

• Darstellungsprobleme bei Sonderzeichen im Artikel erledigt

Ich hab die Seite jetzt komplett auf UTF-8 umgestellt, sollte also OK sein. --Reinhard Kraasch 11:30, 22. Jan. 2009 (CET)

• Default-anzeige auf 'aktive' Mentoren erledigt

(grund: bei den ex-mentoren ändert sich ja nix mehr. die braucht man eigentlich nur einmal gesondert abzufragen... danach könnten deren ergebnisse als statische seiten gespeichert werden - schnelleres abfrageergebnis) --NB/archiv 15:23, 23. Jan. 2009 (CET)

verwendbarkeit:

manuell: als ersatz für das ~escaladix-tool - das lässt sich nur noch mit mühe benutzen...

online: (noch) nicht verwendbar, abfrage-ergebnisse dauern noch zu lange. API-bugfix abwarten.

Passwortschutz

Für die weiteren Tests werde ich den Passwortschutz einrichten (derzeit schon bei der Mentorensuche aktiv) - der Schutz wird nicht allzu dicht sein, wir haben es ja nicht mit wirklich geheimhaltungsbedürftigen Daten zu tun, daher speichere ich auch das Login bzw. Passwort in Cookies, so dass man sich nicht immer wieder neu anmelden muss. Wer im passwortgeschützten Bereich weitertesten will, kann mich anmailen, ich schicke ihm dann das Passwort zu (alternativ: teilt mir Euren Passwortwunsch mit...). Der Einstieg in die (Unter-)Website ist jetzt http://www.dbwiki.de/mp --Reinhard Kraasch 20:59, 22. Jan. 2009 (CET)

• Passwort-Login via Cookies erledigt
• Layout-probleme - zu breit; erzeugt horiz. scrollbalken bei standardauflösung (1024x768). nicht jeder hat einen breitbild-monitor ;) !
• Browser-anpassungen - unterschiedliche darstellungen in IE und firefox. IE : index-frame unsichtbar ohne 'mouseover' / firefox : sichtbar

Ja, am Layout bin ich gerade dran. Vielleicht mach ich doch eine Frame-Seite daraus, auch wenn Frames igitt sind... (d.h., jetzt ist erst einmal Schluss für die nächsten Tage, ich bin übers Wochenende unterwegs). --Reinhard Kraasch 15:39, 23. Jan. 2009 (CET)

...mach mal pause, Reinhard - du hasts dir doch redlich verdient! p.s.: ich meine, frames ham sich nach sovielen jahren (zumindest quantitativ) im www durchgesetzt. das hauptproblem waren doch die damaligen suchmaschinen, die damit nich umgehen konnten ;) ! gruß, --NB/archiv 15:57, 23. Jan. 2009 (CET)

WEBDESIGN

...ich hab auch so'n großen bildschirm wie du - deshalb sehe ich die seiten so: IE Breitwand firefox breitwand...

aber die meisten sehen es leider nur so: IE 15-17 zoll firefox 15-17 zoll (letzterer noch akzeptabel)...

deshalb würde ich jedem entwickler empfehlen, sich auf eine browser-rahmengrösse zu beschränken, die dem standard entspricht...

Am Webdesign hab ich doch - wie oben ja schon geschrieben - noch gar nicht gearbeitet (die Styles usw. stammen von meiner Kiosk-Version der Botanik-Datenbank, wie man schon an der Grünfärbung sieht...): Wie schon an anderer Stelle gesagt: Diese Seite diente

• als Test, wieweit die API-Funktionen von PHP aus angesprochen werden können
• als Test der neuen Datenbank

Zunächst wollte ich eigentlich die Datenbankstrukturen in trockene Tücher bringen, und gleichzeitig festlegen, was die Datenbank können soll oder muss. Webdesign ist dann wieder eine ganz andere Baustelle ... Aber ich sehe schon, konzeptuell wird das hier nichts, ich ziehe mich daher aus der Diskussion erst einmal zurück und komme wieder, wenn ich etwas Tragfähiges habe. --Reinhard Kraasch 13:59, 29. Jan. 2009 (CET)

...hätte ich das bloß nich geschrieben, das mit dem webdesign - mein eigenes iss ja auch nich grade umwerfend... es tut mir leid, mich so ausgedrückt zu haben. dachte nur, sowas wird oft vergessen - man erhält ja auch auf WP-benutzerseiten sehr oft diese horizontalen scrollbalken... war nich bös gemeint, sorry gruß, --NB/archiv 17:41, 29. Jan. 2009 (CET)

Idee (Jón)

Hallo zusammen, nachdem mich Ulli darum gebeten hatte, will ich hier kurz eine Idee skizzieren, dich ich im Zusammenhang mit dem MP und der Datenbank hatte. Es wäre toll, wenn man ähnlich wie WP:PB eine zentrale Seite hätte, wo die Mentoren ihre neuen Mentees eintragen und wieder austragen. Analog zu WP:PB könnte dann ein Bot den Eintrag in der Datenbank übernehmen, und man würde damit die doppelte Buchführung verhindern... Grüße von Jón + 20:22, 28. Jan. 2009 (CET)

Mein Plan war eher, die Datenbank zum Zentrum der Aktivitäten zu machen, d.h. sie beispielsweise dazu zu bringen, die Listen zu pflegen und die Kategorien abzugleichen. Das ganze nicht vollautomatisch, sondern benutzergesteuert - d.h., wer will, kann dann mittels der Datenbank die Listen pflegen (auch für andere, wenn er da einen Bedarf sieht - wie es ja auch jetzt schon gehandhabt wird), wer's lieber manuell macht, kann das natürlich weiterhin tun (allerdings auf die Gefahr hin, dass ihm jemand anderes beim Ein- oder Austragen zuvor kommt). Die Anforderung geht halt schon ein bisschen weiter als bei den PB, neben dem reinen Ein- und Austragen gilt es ja auch, eine Artikelstatistik zu führen. Zusätzlich habe ich noch vor, eine Bewertungsmöglichkeit für die Artikel der Mentees (und ggf. auch für die Mentees selber) zu schaffen. Das geht - wenn man Wert auf Datenintegrität legt - eigentlich nur direkt in der Datenbank. --Reinhard Kraasch 22:07, 28. Jan. 2009 (CET)

...ich finde die idee trotzdem gut. diese 'zentrale seite' hätten wir ja schon: die neulingsbörse bzw. die kategorie Wird im Mentorenprogramm betreut. der bot (z. b. Eukus Benutzer:SpBot) könnte diese kat alle 10 min. auslesen, und die veränderungen dann in die db automatisch eintragen. kontrollfunktion wäre dann noch der vierfach-check. eventuell wäre auch die archivierung automatisierbar - da gibts viele möglichkeiten... eigentlich bräuchte zunächst mal am 'workflow' des mentorings garnix verändert werden, aber der arbeitsaufwand wäre erheblich reduziert - vor allen dingen mein eigener ;) - denn von den 1352 mentees habe ich ~700 selber eintragen müssen. das seh ich immer dann, wenn ich mal einen einzigen tag nicht eingeloggt bin... an den tabellen, der artikelzählung, den sql-features usw. kann man ja trotzdem weiterbasteln. wie und was und wo der bot seine updates macht, kann ja jederzeit verändert werden. gruß, --NB/archiv 22:23, 28. Jan. 2009 (CET)

Nur zu zwei kleinen Einzelpunkten: ich denke, eine Bewertung von Mentee-Artikeln und Mentees ist nicht im Sinne des Programms. Stichworte: unnötiger Leistungsdruck, wer soll das ganze machen, es lenkt von der Erstellung der Enzyklopädie ab und wird als zu bürokratisch angesehen (vgl. Strukturfragen, ich hatte selbst mal etwas ähnliches angedacht, vgl. Wikipedia:Mentorenprogramm/Entwurf zu Strukturfragen des Mentorenprogramms, Punkt 8); auch würde ich mir als Mentee seltsam vorkommen, wenn jetzt irgendwer anfängt, über meine ersten Gehversuche zu urteilen. Grüße von Jón + 08:59, 29. Jan. 2009 (CET)

...ja, dies wurde sogar in den allerersten diskussionen so festgehalten - dafür hatte ich mich damals sogar mit Mo angelegt... Reinhard möchte das aber auch garnich nach draussen bringen, sondern eher für die mentoren selbst, quasi als selbstkontrolle des arbeitsergebnisses. und das iss natürlich ok - wer will sich denn schon umsonst abgemüht haben? eine interne beurteilung also. die inhalte der db können ja gefiltert abgesondert werden. was war jetzt der zweite punkt? gruß, --NB/archiv 10:12, 29. Jan. 2009 (CET)

Mal etwas überspitzt und polemisch ausgedrückt (ich unterstelle niemandem böse Absichten, will nur eine mögliche Außenwirkung verdeutlichen): die Mentoren urteilen in Hinterzimmern üner Artikel und Mentees. NEIN! Wenn, sollte man mit dem Mentee das persönliche Gespräch suchen. Diese Richtung ist aus meiner Sicht nicht akzeptabel und eine mögliche Gefahr für die Glaubwürdigkeit des Programms. Entschuldigt die harschen Worte. Grüße von Jón + 12:30, 29. Jan. 2009 (CET)

Es ist doch völlig Wurst, wer jetzt wo die Bewertung macht - ob man das jetzt in einer Excel-Tabelle auf dem heimischen PC macht oder in einer allen Mentoren zugänglichen Datenbank macht oder wie auch immer. Auf jeden Fall halte ich eine Qualitätskontrolle für notwendig (letztendlich: nur dafür machen wir den ganzen Pipifax mit der externen Datenbank überhaupt - wenn es nur darum geht, den Zu- und Abgang der Mentees zu verwalten, brauchen keine Datenbank). Die Teilnahme der Mentoren ist ja auch völlig freiwillig - aber dass sich die Mentees (und auch das Mentorenprogramm) bewerten lassen müssen, liegt nun mal in der Natur eines offenen Projekts, in dem die jeweilige Leistung nun einmal völlig offen liegt. Ich sehe darin nichts Frevelhaftes. Und was die Glaubwürdigkeit angeht: das Mentorenprogramm muss sich schon fragen lassen, ob es summa summarum zur Verbesserung von Wikipedia beiträgt oder eher zum Gegenteil. Und das geht eben nur, wenn man von der reinen Artikelzählerei wegkommt und z.B. einen unerträglichen Substub eines mittlerweile gesperrten Mentees nicht als "hat einen tollen Artikel erstellt" wertet. Und das wiederum geht halt nur, wenn man den Artikel bzw. den Anteil des Mentees daran bewertet. --Reinhard Kraasch 13:53, 29. Jan. 2009 (CET)

Hallo. Wenn ich euch richtig verstehe soll das so ablaufen: Kategorie:Wird im Mentorenprogramm betreut wird vom Bot alle 10 Min. ausgelesen und mit einer Liste (wie t_allids.cfm bei PB) aller Mentis, die auf Ullis Server liegt, verglichen. Wenn es neue Benutzer gibt, werden die Namen an ein Formular gesendet und damit in die DB eingetragen. Muss noch etwas gemacht werden? Wenn das alles ist, werde ich mich in den kommenden Tagen daran setzen. "Tage", weil ich im Moment im RL beschäftigt bin. Soll auch etwas geschehen, wenn sich in der Kategorie ein Name nicht mehr findet, aber noch in der DB (z.B. durch Austragen der Kategorie)? --Euku:^⇄ 12:10, 29. Jan. 2009 (CET)

Ja, so in etwa hab ich mir das gedacht, ohne jetzt die Feinjustierung genau zu kennen. Am Ende soll niemand mehr in die "Neulingsbörse" unter WP:MP/O oder in der Datenbank eintragen müssen, sondern das macht der Bot automatisch, nachdem man auf einer zentralen Seite gesagt hat, User:XYZ wird von Mentor:ABC (nicht mehr) betreut. Kleine programmiertechnische Probleme können z.B. dann auftreten, wenn ein Alt-Mentee wieder ins Mentorenprogramm aufgenommen wird, was neulich zu einigen Korrekturen in der Projektorganisation geführt hat (aus Archiv streichen, Nummern ändern, ...) - Grüße von Jón + 12:30, 29. Jan. 2009 (CET)

Na ja, das ist eigentlich nur ein kleiner Teilaspekt (den ich eigentlich schon - in der neuen Datenbank - realisiert habe). Die Kernfrage ist und bleibt natürlich: Wozu überhaupt die Datenbank? Wenn es nur darum geht, die aktuellen oder ehemaligen Mentees und Mentoren zu verwalten, brauchen wir wie gesagt keine Datenbank. Und wenn man's schon macht: Der eigentliche Trigger ist das Setzen der Kategorie "wird im Mentorenprogramm betreut" - die daraus resultierenden Listen sind ja dann schon wieder der zweite Schrittt. Eine Zusatzseite anzulegen, in der man die Ein- und Austragungen einträgt, halte ich für unnötig (das wäre der vierte Schritt...). Eigentlich war die Seite hier dazu gedacht, ein Datenbankkonzept zu entwickeln - jetzt wird hier schon wieder über alle möglichen Zusatzaktionen und Oberflächengestaltungen, über Timeouts und Cookies usw. usw. diskutiert, die mit dem Datenbankkonzept bestenfalls mittelbar zu tun haben. Also auch hier der vierte Schritt vor dem ersten. So kann ich nicht arbeiten, ich werde mich daher aus der Diskussion zurückziehen und etwas Tragfähiges entwickeln. Und wenn ihr's nutzen wollt, könnt ihr's tun und wenn nicht, nutze ich es halt alleine. --Reinhard Kraasch 13:53, 29. Jan. 2009 (CET)

...@Euku: danke daß du dich gemeldet hast - und dich demnächst dransetzen willst! es wäre zunächst mal wirklich nich mehr, als das von dir beschriebene (bei unregelmässigkeiten wie dem plötzlichen fehlen in der kat lieber nix automatisch machen - iss oft nur ein ungewolltes versehen!). wir können ja nochmal entsprechend mailen, es wäre tatsächlich nur ein zusatz zu der schon bestehenden bot-arbeit auf dem server...

...@Reinhard und Jón: es war wohl meine schuld, daß es hier missverständnisse gibt - und zwar deshalb, weil ich hier die beiden anliegen bezüglich der db-anwendung zusammengemixt hab. da ist einmal die von Reinhard angestrebte qualitätssicherung des mentoring mit hilfe einer db, die dafür natürlich etwas anders aussehen muss als die bisherige. und zum anderen läuft da die jetzige db, die für die projektorganisation gedacht war, und mir für die mülltonne derzeit noch zu schade iss. daß wir die eigentlich garnicht brauchen, sehe ich jedoch nicht so. ich glaube immer noch daran, daß beides wichtig ist und daß man beides auch sinnvoll kombinieren kann.

Wenn ich ehrlich bin: Ich glaube, das Mentorenprogramm verwaltet sich hauptsächlich selbst. Ihr habt ja woanders schon festgestellt, dass ich derzeit schlappe 40 Mentees habe - die mich praktisch gar nicht ins Schwitzen bringen (siehe die Aktivitäten auf meiner Diskussionsseite...). Die meiste Arbeit macht das Ein- und Aus- und Umtragen in den diversen Listen (und eben: in der Datenbank). Und ebenso ehrlich gesagt: Wenn jetzt ein Mentee fälschlich als inaktiv oder halt doch als aktiv oder als nicht mehr aktiv gekennzeichnet wird - wen kümmert's? Wenn mich jemand etwas fragt, antworte ich ihm, ob er jetzt den "Wird betreut"-Baustein auf seiner Seite hat oder nicht, ob er "aktiv" ist oder nicht. Und, ja, ich würde den Mentees gerne beim Erstellen neuer Artikel helfen, aber wirklich als Autor tätig ist von den 40 ein einzelner! Und seinetwegen der ganze Aufwand... --Reinhard Kraasch 21:29, 29. Jan. 2009 (CET)

TO DO

abarbeiten der ex-mentoren/ex-mentees: ulli

...@Reinhard: die alphabetische reihenfolge bei den mentee-artikelgruppen ist verwirrend: besser wäre eine chronologische - dann wäre auch der erstellungs-zeitraum deutlicher! ich habs mal manuell umgestellt...

p.s.: ein typisches php-cookie-ergebnis ist diese nervige fehlermeldung "diese webseite ist abgelaufen" - wenn man nach 10 min. oder so ähnlich bloß wieder 'zurückspringen' will... dann muß man die ganze mehrere minuten dauernde abfrage wiederholt stellen. zumindest im ie-explorer. aus solchen gründen mag ich cookies nich... entweder ich bin authentifiziert - und dann isses egal, wielange ich draussen war - oder eben nich. denn selbst wenn sich der db-inhalt zwischenzeitlich verändert haben sollte: von ColdFusion-servern bekommst du immer ausschließlich das aktuelle ergebnis...

Ist ja alles noch nicht fertig - im Produktionssystem werde ich den Session-Timeout höher setzen und die Fehlermeldung abfangen (d.h. man kommt dann halt auf die Login-Seite...). Die Sortierbarkeit ist auch ein Thema (hab ich z.B. auf der Mentoren-Suchseite realisiert). Ansonsten: Siehe unten... --Reinhard Kraasch 13:02, 29. Jan. 2009 (CET)

...war (wie alles andere auch) nicht destruktiv gemeint. ich schätze deine arbeit hier sehr viel höher ein, als es rüberkommt - vielleicht sollte ich, frei nach Dieter Nuhr „einfach mal die fresse halten“ und bischen weniger rummäkeln... gruß, --NB/archiv 20:36, 29. Jan. 2009 (CET)

Erst mal Pause

Ich muss derzeit die Arbeit an der Datenbank etwas hintendran stellen, da sich mein Botanik-Projekt in den Vordergrund drängt (die Datenbank soll zur Eröffnung des Loki-Schmidt-Hauses fertig sein...) Ausserdem hilft mir der Verlauf der Diskussion hier nicht wirklich weiter - ein Datenbankkonzept (und darum sollte es zu allererst mal gehen) ist etwas anderes. Auch hab ich wohl zu wenig herausgestellt, dass meine Webseite kein fertiges und diskussionsfähiges Produkt, sondern eine reine Machbarkeitsstudie ist. --Reinhard Kraasch 13:02, 29. Jan. 2009 (CET)

fazit (nach einem halben jahr)

• die ganze sache brauchte damals 'rohdaten' (wer hat(te) welchen mentee, von wann bis wann), und diese stellte ich zur verfügung, indem ich den damals aktuellen stand der DB übergab...
• man kann kaum behaupten, wir "bräuchten eigentlich überhaupt keine datenbank" - der beweis liegt auf der hand: wenn man heute nochmal abfragt, hat sich am ergebnis nix geändert, weil ja inzwischen sehr viel neue dazugekommen sind, die aber nicht erfasst wurden.
• da müsste also erstmal meine db(oder deren ergebnisse) permanent gescannt werden, nur um an diese daten zu kommen ;) !
• das nenne ich "von hinten durch die backe geschossen": dann doch lieber gleich auf dem server abwickeln, der sowieso schon 'online' iss...
• was von den toolservern zu halten iss, hat sich für mich auch negativ bestätigt: ausfälle in einem (untragbaren) zweistelligen prozentsatz-bereich. da lob ich mir die performance plus zuverlässigkeit(uptime) meines eigenen servers - so gut wie keine ausfälle in mittlerweile zwei jahren am stück!
• am besten verfahren wir weiter so wie bisher - es wäre ausreichend, monatlich einmal upzudaten.
  1. alle artikel der aktuellen mentees(NB) plus
  2. alle artikel der archivierten mentees(Archiv) - jeweils für den monat; sind ca. 60-120
  3. wenn man dann noch die erstartikler durchgeht, müsste eigentlich alles erfasst sein...
• hört sich nach viel arbeit an - isses aber de facto nich. vor allem dann nich, wenn sich mehrere leute die arbeit aufteilen...