Nachtgeist

Versuch dich mal mit SHOW TABLE STATUS; Das duerfte in etwa das zurueckgeben, was du willst ... EDIT: hier noch die Doku dazu: http://dev.mysql.com/doc/mysql/en/SHOW_TABLE_STATUS.html

Tut es auch nicht. Die Plans werden schliesslich gecached. Die Plans im Cache werden - je nach DBMS und Konfiguration - aus dem Cache entfernt, wenn sie zu alt sind. Wenn ein Plan laenger nicht gebraucht wird ('aging'), wird er also entfernt. Das DBMS kann erstmal nicht wissen, ob das selbe Statement nochmal abgesett wird oder nicht. Wenn du aber genau so eine Anwendung hast, kannst du dein RDBMS in der Regel entsprechend tunen. Eine der Seiten, die ich oeben gepostet habe, beschreibt das Aging fuer den MS SQL-Server ganz gut. Spaetestens dann fliegen alte Execution Plans aus dem Speicher ...

welches RDBMS verwendest du?

http://www.databasejournal.com/features/mssql/article.php/3067071 Because the stored procedure execution plan can be outdated, for example when large amounts of data modifications are made to a table referenced by a stored procedure, you may need to recompile the execution plan. SQL Server 2000 automatically recompiles the stored procedure execution plan when one of the following conditions are met: [...] Ausserdem lesenswert: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_sa_4azp.asp und: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_da_0nxv.asp SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans. Jedes moderne RDBMS handhabt das so. Weil sie in Form einer Funktion (Prozedur) auf dem Server abgelegt (Stored) werden.

Ein Execution Plan wird auf Statement-Ebene definiert und das fuer jede Datenbankabfrage. Ob die Abfrage jetzt ueber eine SP, einen View oder einem SELECT abgesetzt wird ist dabei egal. Desweiteren kann sich der Execution Plan von Zeit zu Zeit aendern. (Ausser die Datenbank dahinter aendert sich nicht.) Auch bei Prozeduren. Das der Execution Plan bei Views oder nacktem SQL jedesmal neu erstellt wird stimmt nicht. Der wird gecached und bei identischen Abfragen erneut verwendet. Genau wie im Fall einer SP. Kannst du deine Aussage, dass Prozeduren generell schneller sind, als Views (und sei es nur bei einem besimmten RDBMS) sinnvoll belegen?

Ein weiterer guter Anwendungszweck fuer Views...

Ne andere Moeglichkeit sehe ich gerade nicht. Ich wage sogar zu behaupten, dass das der einzig praktikable Ansatz ist ... (fuer eine Alternative waer ich aber trotzdem zu haben )

Freshmeat hat da was im Angebot

Views sind z.B. gut um fuer eine Anwendung (Frontend, Reportgenerator, whatever) eine vereinfachte Version einer komplexen Datenbankstruktur (z.B. Warenwirtschaftssystem) zur Verfuegung zu stellen, die ausserdem Strukturaenderungen in der grundlegenden Datenbank kaskadiert, so das man die Anwendung nicht jedesmal aendern muss. Updates lassen sich dann entweder ueber Trigger auf den Views (sehr bequem, feine Sache ) oder ueber der Anwendung als Funktionen bereitgestellte stored procedures umsetzen. Wenn deine Datenbank keine Views zur Verfuegung stellt, koenntest du schauen, ob das PHP (oder womit du das auch immer auf dem Webserver machen willst) SQLite unterstuetzt. Das kann Views und - eingeschraenkt - auch Trigger.

Ich habe das bisher nur fuer Black/Whitelists, Benutzerdatenbanken, Greylisting etc. benutzt, kann dir das also nicht beantworten. Diese Zeiten lassen aber vermuten, das bei dir was im Argen ist. Wie hast du das denn realisiert?

Du kannst LDAP-Verzeichnisse und diverse Datenbanken als Tables in Postfix einbinden. Links zu entsprechenden HowTos sollten sich auf der Postfix-Seite finden lassen. Du braucht allerdings einen entsprechend gebauten Postfix ... Alternativ kannst du das auch ueber einen Policy-Daemon loesen. Fuer diesen Zweck habe ich aber noch keinen gesehen - da waere dann wohl Handarbeit angesagt ... (Die ganzen Greylisting-Daemons fuer Postfix verwenden das. Da kann man sich sicher was abschauen.)

samba.org -> 'learn samba'

Schonmal 'convert' von ImageMagick probiert? Der macht das bei mir ganz fein ...

Viele syslogds koennen koennen die Logs per Pipe an ein Programm weiterschieben. Schau einfach mal in SYSLOG.CONF(5) vorbei, ob deiner das unterstuetzt. (Wenn nicht ist es normalerweise auch kein Problem, sich einen anderen zu installieren)

Mein Chef wuerde mich totpruegeln, wenn ich meine Arbeitszeit mit sowas verschwenden wuerde. Sinnvoll waere es wohl, einen logwatcher auf das authlog anzusetzen, der dir mehrere Fehlversuche von einer Quelle aus zusammenfasst. (z.B. in einem neuen Logfile) Damit drueckst du die Anzahl der Meldungen wenigstens auf a) die Relevanten und auf eine ertraegliche Menge.

Ich wuerde das ueber einen content_filter realisieren. Zumindest wuerde ich da als erstes mal ansetzen. Aso aeh ja und das Signieren dann ueber PGP?

Sowas steht in /var/log/authlog und sie ca. so aus: Das hat man bei einer Kiste, die am Internet haengt ca. 200mal am Tag. Das willst du sicher nicht jedes mal nachverfolgen.

Du willst die /etc/profile benutzen. Da koennen die User naemlich nicht drinn rumruehren ...

Wenn du deinen Server absichern willst, solltest du dich nicht mit den (relativ) sicherem SSH aufhalten, sondern dir Gedanken ueber die (Konfiguration der) restliche Software machen.

http://www.google.com/search?hl=en&lr=&q=Linux%2FUnix+Shell+Tutorial++pipes

geht btw auch mit awk -F\' ...

man sshd(8):

http://wwwold.bayarea.net/bayarea/majordomo.admin.html

http://freshmeat.net/search/?q=mysql&trove_cat_id=68&section=trove_cat Such dir was aus.

Schau dir mal das an: http://www.postgresql.org/docs/7.3/static/indexes-multicolumn.html Du solltest schauen, ob du fuer deine Queries auch die passenden Indizies parat hast.