just_me

Wenn du es wirklich handmade lösen willst, wirst du an der Windows Management Instrumentation (WMI) wohl nicht vorbeikommen. Jedenfalls nicht, wenn du Wert auf effektive Arbeit legst, die sich nahtlos einbinden lässt. Wenn du es administrativ lösen möchtest, schau dir mal telnet und die net services commands genauer an. Es macht zwar weniger Spaß, ist aber - zumindest für diesen Fall - weit produktiver, mal "den Pinguin raushängen zu lassen."

Ich finde solche Aufgaben wirklich lustig, und werde mich gern an der Suche beteiligen, aber könntest du bitte " ... beispielsweise ... " ein bisschen genauer spezifizieren? Darf es auch ein anderer Ort, eine andere Zeit oder gar ein ganz anderes Thema sein? - eine lustige Wetter-WebCam, allerdings weder München, noch Temperaturen, noch 1996; sondern ein Essener Parkplatz in 2003 (dafür aber für jeden Tag ein Bild. *lol) - nicht so wirklich spezifisch: der Klimastatusbericht des Deutschen Wetterdienstes - eine erste Annäherung: Rückblick für über 5000 Stationen weltweit bei wetteronline.de (allerdings nur bis 2002) - schon besser: dieser Analyseservice stellt Daten bis 1950 zurück bereit. Haken: Es ist sehr grob aufgelöst, genaue Temperaturen sind nur schätzbar. - sehr genau: Das Wetter in St. Augustin bis zum 1.1.'95 zurück. Ist zwar nicht unbedingt München, eigentlich nicht mal so ganz dicht daneben, aber immerhin: Von Hawaii aus gesehen, liegen die beiden Orte unmittelbar nebeneinander und haben auch so ziehmlich das gleiche Wetter. Gilt das jetzt? - langsam pirschen wir uns dichter: nächster Stopp Karlsruhe; Zeitspanne 1876-1995 - yehaw! Münchener Wetter A.D. 1803 ... *lmao --- über's Ziel hinausgeschossen. - ok, nächster Versuch: Temperaturmonatsmittel München-Riem 1781-1992, blöd! keine Tagestemperaturen. - Treffer! Versenkt! Wetterbeobachtungsarchiv deutschlandweite Wetterdaten von 1876-vorgestern ... [Edit]Oh, ich vergaß: Die Suchzeit betrug ca. 40 min. [/Edit]

Ich auch. Ohne wenn und aber. Schon allein dieser Wille hebt sie aus der grauen Masse deutlich heraus. Ich hoffe doch stark, dass es nicht nur Selbstzweck ist. Doch wie heißt's so schön? Narren lernen, wenn sie lernen, auf eigene Kosten. Der Kluge lernt auf Kosten der Narren. Lass' mich also der Narr sein. Ja, noch vor gar nicht allzu langer Zeit war ich genauso beeindruckt und begeistert, wenn es um den Gedanken eines Studiums ging. Ich glaubte wirklich, so ein Zettel würde mir Tür und Tor öffnen. Heute sehe ich die Dinge ein bisschen anders. Und das ist es, was ich zeigen will: Meine Sicht auf die Dinge. Das sind zwei verschiedene Paar Schuhe. Wenn ich ehrlich sein soll: Den Dipl.-Inf. würde ich mir - rückblickend - heute schenken. Statt dessen würde ich die 4 Jahre (die ich trotz alledem nicht zwingend als verschenkt betrachte) "nutzbringender" damit verbringen, tiefgreifendere fachliche Qualifikation im Ausland zu erwerben. Ich bin damals (gleich nach dem Abschluss) mit stolzgeschwellter Brust nach Amiland gezogen und glaubte an den hierzulande weit verbreiteten Irrglauben, ein Diplom wäre etwas, worauf ich mir was einbilden könnte. Und ich war tödlich beleidigt, als man wiederholt in Vorstellungsgesprächen achtlos über mein ach so mühsam erworbenes Zertifikat hinwegging und schnurstracks die Seiten im CV aufblättern wollte, in denen stehen würde, was ich denn nun genau kann und kenne. Doch da war (noch) nix. Gar nix. Es hat mich reichlich Mühe gekostet, den Leuten klarzumachen, dass dies ein temporärer Zustand sein würde. Diese Erfahrungen haben mich veranlasst, schleunigst die ersten Zertifikate zu machen. ... Der Rest ist Sucht. Der Sog des "wissen wollen's" zieht mich immer tiefer in seinen Bann. Heute sehe ich mich in der glücklichen Lage, bei entsprechenden Verhandlungen mit den Worten "Suchen Sie Sich aus, was Sie brauchen." einen Packen Zertifikate auf den Tisch zu werfen. Und DAS ist es, was wirklich zählt. Das Diplom ist dabei kaum mehr als Kosmetik und nette Garnitur. Und was die politischen Ereignisse betrifft: Trotz des - imho haarsträubenden §3 der Regeln dieses Forums - ein paar "politische" Worte dazu. Die großen und kleinen Parteien dieses Landes streben nachhaltig an, den Markt "zu befreien". Sie nennen es zukunftsweisend. Ich nenne es "Amerikanisierung". Abgesehen von den sozialen Kollateraleffekten hat es auch Auswirkungen auf die Branche. Diese jedoch jetzt umfassend darzulegen würde den Rahmen dieses Forums deutlich sprengen. (Wenn es dich interessiert, können wir es gern an anderer Stelle erörtern.) Angenommen, diana plante tatsächlich das Abi in der VHS nachzumachen und anschließend ein Fernstudium aufzunehmen. Das würde bedeuten, dass sie - optimistisch gewertet - ca. 5-6 Jahre einplanen müsste. Realistisch werden es wohl eher ca. 7-9 Jahre, bevor sie das Diplom in der Tasche hat. Abgesehen davon, dass diese durchaus lange Zeit insbesondere bei nebenberuflicher Weiterbildung damit gefüllt wird, Tag für Tag, Woche für Woche und Jahr für Jahr bis spät in die Nacht über Büchern zu hocken; was denkst du, wie der Markt in 7 oder 8 Jahren aussieht? Glaubst du wirklich, ein Diplom nutzt so viel, dass es Praxiserfahrung ersetzen kann? (Das Gerücht mit der "Praxiserfahrung en passant" beim Fernstudium hält sich hartnäckig, ich weiß. Listigerweise ist es nicht zuletzt ein schlagkräftiges Argument, das Fernstudium zu beleben.) Oder schlimmer noch: Nehmen wir an, sie findet den Titel "BSc" (Bachelor of Science, Bakkalaureus oder "Hilfs-Akademiker") lustig. Dann investiert sie 4-5 Jahre, nur um anschließend zu erkennen, dass sie weitermachen sollte. Oder "MSc" (Master of Science)- toller Titel, nicht? Dahinter verbirgt sich - in einer Zeit, in der Hausmeister "house manager" und Verkäufer "sales manager" heißen - nichts anderes als ein "Akademiker-Geselle"; ein Anwärter auf Intelligenz sozusagen. Noch einmal: Ich halte Bildung für wichtig - ebenso wichtig, wie atmen und denken. Aber - um es mit dianas Worten zu sagen: Und längst nicht alles was gestern gut war, muss auch heute oder gar morgen noch Gültigkeit haben.

<just a thought> Ich fürchte, du versuchst der Zeit hinterherzulaufen. Dein Vorhaben mag edel sein, deine Ziele ganz sicher hehr, aber allein ein kurzer Blick auf politische Ereignisse und die (theoretische) timeline deiner Entwicklung zeigen, dass der Versuch, ein Studium "nachzuholen", kaum mehr als idealistisch sein kann. Ich halte es da mehr mit Thomas v. Kempen, der einst sagte *Wenn das Leben mit dem Wissen in Einklang steht, dann hat man recht studiert.* Jetzt mal im Ernst: Meinst du der Titel beeindruckt wirklich jemanden im ÖD? Vielleicht sollte ich das dann immer dazuschreiben: Dipl.-Inf. just_me, MCP, MCSA, MCSE2k, MCSE2k3, MCSE: Security, MCDBA2k, MCAD, MCAD.NET, MCSD, MCSD.NET und "MCDST in spe" Und? Beeindruckt? Nicht wirklich, oder? Jedenfalls ganz sicher nicht vom Titel "Dipl.-Inf.", hm!? (Hast du den überhaupt entdeckt?) </just a thought>

Ich glaube, die Kernfragen, um die sich alles drehen wird, und auf die sich (zumindest gegenwärtig), bezogen auf deinen Werdegang, alles reduzieren lässt, lauten: A1 [_] Ich tendiere eher zum Generalismus und habe mit Spezialisierung nur wenig am Hut. Meine Stärken sehe ich definitiv im strategischen Management. B1 [_] Ich neige eher dazu, mich spezialisieren zu wollen. Meine Stärken sehe ich eindeutig darin, Experte auf einem und/oder mehreren Gebieten zu werden. A2 [_] Ich möchte gern Karriere machen. B2 [_] Ich möchte "lernen um des Wissens willen". Auflösung: ========== Falls du dich für A1 und A2 entscheidest, ist ein Studium sicher angebracht. Welches, ist allerdings an deine Neigungen angelehnt. Ratsam wäre sicher ein technisches Studium mit dem Schwerpunkt auf BWL (möglicherweise Wirtschaftsinformatik oder BWL). Die Entscheidung für B1 und B2 bringt dich meilenweit weg von einem Studium. (Zumindest, wenn du an ein Studium in Deutschland denkst.) Vielmehr wäre es dann ratsamer, in deinem aktuellen Fach-/Interessengebiet nach Zertifikaten zu graben. JAVA? Sun! .NET? Microsoft! Datenbanken? Oracle, Microsoft, IBM, MySQL! ... XML, UML, OOA/D/P ... und, und, und ... sind nur einige der "Spielwiesen", auf denen du dich nach Herzenslust austoben kannst. Wenn deine Wahl auf A1 und B2 fällt, solltest du vielleicht an eine Zertifizierung im Bereich Security und/oder Projektmanagement denken. Symantec, Microsoft, die University of Texas und Management Concepts seien hier stellvertretend genannt. B1 und A2 hingegen ist eine leidliche Kombination, die viel mit Glück zu tun haben wird ... Auch wenn ich es uneingeschränkt befürworte, wenn sich jemand Wissen aneignen will, so möchte ich doch zu bedenken geben, dass ein Studium - und hier insbesondere in der IT - heuer alles andere als ein Jobgarant ist. In den vergangenen Jahren hat der Markt ein deutlich erkennbares Sättigungsniveau angenommen, das, und dazu muss man kein Prophet sein, auch in 4 oder 5 Jahren nicht nachgelassen haben wird. Hinzu kommt, dass so manche Uni verträumt-weltvergessene Lehrmethoden hat, und selbst einige FH's alles andere als zukunftsorientiert unterrichten. Ja, ein Diplom (welches ja letztlich Ziel der Übung sein sollte) ist schon nett anzuschauen, in den aktuellen Zeiten aber keineswegs eine ultimative Fahrkarte zu Glück, Geld und interessanten Arbeitsaufgaben. Naja, und nicht zuletzt: Ein Studium dauert ca. 4-5 Jahre (ein Fernstudium 5-8 Jahre). Wer hätte vor nicht einmal 3 Jahren geglaubt, dass es einmal hunderttausende arbeitsloser Informatiker geben wird? Wer will also heute dafür garantieren, dass man sich nicht seine eigenen Chancen "wegstudiert"? Ich sehe momentan die Lösung darin, sich dem Markt anzupassen. Und der schreit nach Fachspezialisten aller Coleur die zumindest ansatzweise Kenntnisse der tangierenden Technologien besitzen. Ich meine, schaut sie euch an, die Ausschreibungen: IT-Specialist, Softwareentwickler Middleware, Datenbankspezialist, ... Ihnen ist eines gemeinsam: Obwohl sie nach "Spezialisten" rufen, verlangen sie doch Kenntnisse "über den Tellerrand" eines Fachgebietes hinaus --- ohne jedoch zum Generalismus zu tendieren. ... aber jetzt fange ich an, zu agitieren ... :floet: In diesem Sinne, dubito, cogito, ergo sum. [Descartes] oder, um es mit Goethe zu sagen: Denken und Tun, Tun und Denken, - das ist die Summe aller Weisheit. Beides muß wie Aus- und Einatmen sich im Leben hin und wider bewegen; wie Frage und Antwort sollte eines ohne das andere nicht stattfinden.

ouch. my fault, sorry. Versuch's doch mal mit dem bereits vorgeschlagenen SELECT * FROM [Datenbankname].[Besitzer].[Tabellenname], [Datenbankname].[Besitzer].[Tabellenname]Natürlich musst du in beiden Datenbanken über entsprechende Berechtigungen verfügen.

@Patrick.Karre @bigpoint Yep, fein beobachtet. Der - alles tragende - Unterschied ist jedoch, dass die Verbindung zu diesen Servern nicht statisch gehalten werden muss. Somit ist eine Lastbeschränkung möglich, ohne Datenfragmentierung und/oder andere Folgeerscheinungen in Kauf nehmen zu müssen. Während man also für gewöhnlich OPENROWSET verwendet, wenn einmalige oder sehr seltene Abfragen erfolgen, wird man üblicherweise zu OPENQUERY greifen, sobald eine Reihe von Aufträgen kontrolliert ausgeführt werden sollen, die über einen definierten Start- und Endzeitpunkt verfügen. Sinn machen statische Verbindungsserver bespielsweise, wenn "echte" verteilte Systeme existieren, die es erforderlich machen, dass nicht deterministische Datenmengen über nicht deterministische Zeiträume bewegt werden. Diese Annahme, wie auch weitere entsprechende, lässt sich jedoch aus der spezifizierten Anforderung nicht erkennen. Ebenso, wie nach wie vor nicht erkennbar ist, welche der genannten Möglichkeiten nun den Idealfall darstellt.

*lol, yep. Paint überschreiben und selbst zeichnen.

Die Frage ist, wie oft du diese Daten brauchst. Für einmalige oder seltene ("Selten" meint weniger als einige hundert Mal/Tag) Abfragen, oder Abfragen, die nur wenige Resultate zurückgeben, ist es denkbar negativ für die Server- und Netzwerkauslastung, wenn du einen statischen Verbindungsserver einrichtest. Hier sind die pass-through-statements (s. OPENQUERY) oder die ad-hoc-Variante (s. OPENROWSET) wesentlich effektiver. Schau dir einfach mal die Onlinedokumentation (Stichwort: Verteilte Abfragen) an. Dort findest du auch ausgezeichnete Beispiele, wie der genaue Syntax für die entsprechenden Anforderungen lautet.

Ich habe mit einigem Interesse die Beiträge zu deinem Schicksal gelesen, und ich hoffe ehrlich, dass dein Pech nun bald ein Ende hat. Doch trotz aller - durchaus verständlicher - Frustration, die du jetzt verspüren magst, solltest du darauf verzichten, diese an andere (auch und gerade die neue Firma ist gemeint) weiterzugeben. Das Anschreiben insgesamt ist ein subtiles Mittel, mit dessen Hilfe dein potentieller Arbeitgeber weit mehr erkennen kann, als du ihm mit Hilfe deiner Worte zugestehen möchtest. Daher ist es wirklich wichtig zu wissen, dass jeder Satz, jedes Wort, jedes Zeichen gründlich studiert wird. Auch (und gerade) die Informationen "zwischen den Zeilen" leisten zu diesem ersten Gesamtbild von dir einen nicht unbedeutenden Beitrag. 1. Es ist nicht opportun, deinen alten Arbeitgeber in einen schlechten Licht darzustellen. Zum Einen wirst du sicher schon von den "üblichen" Arbeitszeugnissen gehört haben, die IMMER freundlich formuliert sind, aber in denen ein einziges Wort darüber entscheidet, ob die Aussage nun positiv oder negativ zu werten ist; zum Anderen sitzt der "Personaler" da, und überlegt, was du wohl den anderen erzählen wirst, wenn du von dieser Firma mal - im Bösen oder nicht - weggehen wirst. Versuche, es als - ja, positive - Erfahrung zu sehen, und werte in deinem Anschreiben in keinem Fall negativ. Natürlich solltest du den Grund nicht verschweigen, und schon gar nicht lügen, aber wenn du die Darstellung vernünftig formulierst, und die tatsächlichen Gründe näher darstellst, dann ist damit allen gedient: Gehst du nun weg, weil du unzufrieden bist (Wenn ja, WAS willst du BESSER machen/haben? Hier könntest du beispielsweise ganz einfach anklingen lassen, dass du dich derzeit unterfordert fühlst.) oder gehst du weg, weil die Firma unzufrieden war? (In diesem Fall könnte sie sich geweigert haben, dir einen Ausbilder zu stellen, weil man der Ansicht war, es sei verlorene Mühe, dir etwas beibringen zu wollen.) 2. Wenn ich du wäre, und mir die Firma, bei der ich mich bewerben wollte, WIRKLICH am Herzen läge, würde ich mich über das Umfeld sehr genau informieren. Nichts ist peinlicher, als ein Antwortschreiben á là : "Sehr geehrter Herr sturmflut, mit großem Interesse haben wir Ihre Bewerbung gelesen, müssen Ihnen aber zu unserem Bedauern mitteilen, dass unsere gesamte IT-Umgebung auf Windows und Novell basiert. Ihre Kenntnisse in Linux ... blablabla ... Wir wünschen Ihnen viel Glück auf Ihrem weiteren Weg. mit freundlichen ... blablabla" Außerdem sieht es jeder Chef gern, wenn seine eigene Firma bekannt ist. Das äußert sich zweifellos nicht zuletzt darin, dass du sagst: "... eine fundierte Ausbildung wünsche, möchte ich diese in Ihrem Unternehmen fortführen.". Allerdings ist das eine der "üblichen" Plattitüden, die immer und von allen verwendet werden. Wie wäre es denn, wenn du ein bisschen gründlicher recherchierst (I'net, anrufen, etc.) und mal schaust, wie es dort aussieht? (Hingehen und fragen ist auch oft gern gesehen.) Auf dieses Telefonat und/oder diesen Besuch kannst du dann referenzieren und es im Anschreiben erwähnen... 3. Formulierungen wie "... selbstständig in meiner Freizeit." und "... Spass an der Arbeit mit Computern ..." kannst du ersatzlos streichen. Sie besitzen <NULL> Informationsgehalt, da selbiges bedingungslos vorausgesetzt wird. Statt dessen solltest dein Anschreiben insgesamt klarer strukturieren, um zu zeigen, dass du tatsächlich in der Lage bist, Informationen zu verarbeiten und prägnant darzustellen. Dazu gehört auch, ein Anschreiben so zu formulieren und zu strukturieren, dass die notwendigen Informationen sofort ersichtlich sind. (Es gibt tausende Vorlagen im I'net, daher ist es müßig, sich hier in Details zu verlieren. Als Zusammenfassung: Absatz 1: Grund des Anschreibens. Absatz 2: Selbstdarstellung. Absatz 3: Warum diese Firma?)

DECLARE @tag datetime SET @tag = DATEADD(d, -7, getdate()) WHILE (DATENAME(dw, @tag) <> 'Montag') SET @tag = DATEADD(d, -1, @tag) [color=green]-- [i]Die beiden folgenden Zeilen geben die berechneten Werte aus.[/i] -- [i]Es ist genauso möglich, diese Daten anderen Variablen zuzuweisen, [/i] -- [i]oder sie in einer Tabelle zur weiteren Verwertung auszugeben.[/i] -- [i]Den Part überlasse ich aber dir, da du keine Spezifikationen angegeben hast.[/i][/color] PRINT DATENAME(dw, @tag) + ', ' + CONVERT(varchar(12), @tag, 106) PRINT DATENAME(dw, DATEADD(d, 4, @tag)) + ', ' + CONVERT(varchar(12), DATEADD(d, 4, @tag), 106) [b]Ausgabe: (gültig für diese Woche)[/b] Montag, 16 Feb 2004 Freitag, 20 Feb 2004

"Gut" ist eine subjektive Bezeichung. Die sogenannten "low level trigger" sind eine quasi-Abstraktion. Alle Trigger benötigen eine gewisse Basisfunktionalität, um ihre Aufgabe sicherstellen zu können. (Beispielsweise würden sich Trigger totlaufen, wenn er beim Update in tbl1 ein Log nach tbl2 schreiben sollte, tbl2 aber im gleichen Augenblick gelöscht wird.) Die Basisfunktionalität zu verarbeiten, kann auf verschiedene Weise geschehen. Einerseits ist es möglich, sie offenzulegen, andererseits kann sie transparent sein. Microsoft hat sich entschieden, diese Funktionalität vor dem Anwender zu verstecken, weil sie eigentlich immer genutzt wird. Die wenigen Ausnahmen, in denen du dasitzt, und dir wünschst, dass du die Möglichkeit hättest, dieses oder jenes direkt zu beeinflussen, wirst du beim MS SQL Server also in Kauf nehmen müssen. Der Vorteil ist, dass du (zwangsläufig) weniger Fehler machen kannst. Und nun entscheide selbst, ob es "gut" ist, wenn man mehr Möglichkeiten hat, die Daten zu fragmentieren, oder ob es "gut" ist, sich nicht auf (im relationalen Datenmodell eigentlich unwichtige) Details konzentrieren zu müssen.

Der Haken an all diesen mehr oder weniger neuen OS' ist eigentlich, dass die Leute die Kosten solcher Entwicklungen nicht überschauen. Natürlich sind viele dieser Ideen grandios - auch ich würde viel lieber das Geld in Bücher oder neue Hardware investieren, als € 399 für ein Betriebssystem auszugeben. Aber leider gibt es da diesen berühmt-berüchtigten Haken: Nach einiger Zeit lässt die anfängliche Euphorie zu wünschen übrig, die Erkenntnis, dass der Ruhm sich doch nicht so schnell einstellt, wie man es sich wünschte, wächst von blassen Schemen zu dunklen Schatten, und - wohl am Wichtigsten - Idealismus macht weder satt, noch lässt er dich trocken schlafen. Es bleibt also die schlichte aber effektive Regel: Geld regiert diese Welt. Solange die großen Konzerne es sich leisten können, riesige Forschungsabteilungen zu unterhalten, und so wie beispielsweise Microsoft Dutzende von Milliarden Dollar in die Forschung stecken, und/oder wahlweise die besten Spezialisten dieser Welt für ein paar hunderttausend Dollar kaufen können, wird es also so bleiben, wie es ist. Da hilft (leider) auch keine Plazebo-Euphorie. Ja, ReactOS ist ein feiner Gedanke. Und ja, ReactOS hat eine gute Basis. Aber ebenso wie OS/2, BeOS und viele andere vor ihnen werden auch sie im Schatten der Bedeutungslosigkeit versinken - gleichgültig, wie gut oder schlecht sie eigentlich sind. Und auch unbeachtet der Tatsache, wie viel Energie die Entwickler aufzuwenden bereit sind. Wie jedes iterative Projekt wächst der Grad der Komplexität von Generation zu Generation. Und nach 30 Mio Zeilen Code hat auch dieses Projekt genau die gleichen 'Kinderkrankheiten', wie Win95 seinerzeit. Nach rund 55 Mio Zeilen Code wird man dann ein Win2k-adäquates Produkt haben. Bei einer Ingenieursleistung von rund 350 Zeilen/Woche kann man sich an 3 Fingern abzählen, wie viele Mannjahre in solchen Projekten stecken. Und da ist noch nicht eine einzige Stunde Analyse, Entwurf oder Debugging inkludiert. Und es fehlt auch die entsprechende Forschung, Dinge "aus dem hohlen Bauch" besser zu machen, bevor sie überhaupt das erste Mal vorhanden sind. Denn genau hier setzt das eigentliche Problem an: Wenn ich ein Produkt sehe(!) und seine Fehler begutachten kann, dann kann ich sehr leicht sagen: "Das und das muss besser werden, wenn wir das nachbauen.", aber ein perfektes Produkt aus dem Nichts entstehen zu lassen, ist weitaus kostspieliger ... ... und da wären wir wieder bei den Kosten ... money makes the world go round

ALTER TABLE tabelle -- zu ändernde Tabelle festlegen ADD spalte int IDENTITY(1, 1) -- Spalte hinzufügennähere Beschreibung siehe MS SQL SERVER Onlinedokumentation. rtfm :mod:

*lol, wo und wie? a) Die Daten befinden sich bereits in einer Datenbank. Dann gib bitte die Spezifikationen der entsprechenden Tabelle/n. (Gibt es eine Spalte für die ID? Welcher Datentyp? Darf/kann die Tabelle/Datenbank strukturell erweitert/verändert werden? etc.) Abgesehen davon: Bei 160 Datensätzen ist es wohl schneller, wenn du die Nummern manuell vergibst, als dir noch stundenlang den Kopf zu zermartern, wie du da schicke Nummern reinbekommst, oder? Die Daten befinden sich noch nicht in einer Datenbank. Wo ist dann das Problem? ID-Spalte einführen, autoincrement setzen, freuen...

Natürlich. Und? Soll er bei -1 beginnen? Oder bei 0? Nach 9 kommt 10, und die hat mehr Stellen. Bei 2'147'483'647 (max. int) hast du dann 10 Stellen. Sind das genug? Falls du den Typ "unique identifier" suchst, der das Format {A16FB25D-884F-4ee1-9FF9-A6C576551676} hat, nun, den gibt es (noch?) nicht im MySQL. Der Irrtum beruht wohl darauf, dass du dem 'unique' zu viel Wert beimisst. Unique heißt ganz einfach "eindeutig". Die Interpretation der Eindeutigkeit kann tabellenweite, datenbankweite oder gar weltweite Grenzen einschließen. Dementsprechend ist eine "unique ID" durchaus unique, wenn man die Grenze auf die Tabelle setzt. Der microsoft'sche unique identifier Typ, den du sicher meinst, ist weltweit eineindeutig - jedenfalls behauptet das Microsoft...

Obwohl ich den Aufwand bei ca. 120 simultanen Zugriffen ehrlich gesagt für übertrieben halte, gibt es bereits anhand dieser Informationsfragmente eine Reihe von Optimierungsmöglichkeiten: Zerlege die Tabelle in zwei Relationen: 1. formelle (statische) Daten, wie Name, etc. 2. informelle (dynamische) Daten, wie Zeitstempel und andere Variablen. Der Rest ist Fleißarbeit... Prinzipiell ist es besser, direkt auf den PK zu suchen. Wenn du also deine statements umstellen kannst, dass sie nach folgendem suchen select from messages where ID = @idwirst du spürbar schneller zu Resultaten kommen. Alternativen: Sicherlich hat Jaraz grundsätzlich Recht, wenn er pauschal feststellt, dass Indizes auf Attribute gelegt werden sollten, die in 'WHERE'-Klauseln vorkommen. Das Indizieren des Empfängers beispielsweise wird dich jedoch allein nicht wesentlich schneller werden lassen. HIER liegt definitiv das größte Performancepotential. Die ID ist ein eindeutiger präindizierter Key. Zugriffe hierauf sind hochperformant. (Deswegen ist es ja ein Schlüssel. ) Setze die Breite des PK möglichst treffend - soll heißen: Rechnest du wirklich mit ca. 9'223'372'036'854'775'807 Benutzern, oder reichen vielleicht auch 4'294'967'295 oder gar 16'777'215 Möglichkeiten aus? - Versuche, wo immer möglich, NUR mit diesem Key zu arbeiten. (Beispiel: 1.: Finden der ID nach dem Benutzernamen, 2...n.: Finden aller Daten nach der ID (evtl. Restrukturieren der Tabellen)) - Wo immer möglich, vermeide Suchen in Strings und BLOBs. Vergleichsoperationen können, insbesondere, wenn viele Strings (Bytes) identisch sind, reichlich lange dauern. (Im Gegensatz dazu sind Suchen in Ganzzahlen extrem performant.) - Optimieren der SQL-Statements bringt immer Punkte. (Der Fragenkatalog hierzu ist umfangreich und ich schreibfaul, aber essentiell sagt er aus: Benötigst du WIRKLICH JEDEN abgefragten Wert, oder reicht auch mal weniger Information?) - Optimieren der Suchbedingungen und Einschränkungen tuned die Performance. Versuche, die Reihenfolge der Einschränkungen so einzurichten, dass sie entsprechend der Wertigkeit ihres Filters stehen: Zuerst die Einschränkung, die die meisten potentiellen Resultate aus- bzw. einschließt, dann die zweitmeisten, usw. usf. Entsprechend dieser Optimierungen, drängen sich mögliche Indizes fast von allein auf... - Versuche, Abfragen blockweise auf Tabellen zu setzen. Mit anderen Worten, frage dich, was du aus der gleich anzufassenden Tabelle für Daten brauchst, und hole sie "in einem Schwung" ab. (Beispiel: Angenommen, du brauchst jetzt den Namen, und 15 Zeilen später den Vornamen, dann hole BEIDE Daten auf einmal ab.) - Gleiches gilt für Inserts und Updates: Führe sie möglichst für eine komplette Zeile gleichzeitig aus. (Sammle die Daten, und füge sie zum spätestmöglichen Zeitpunkt ein.) - Setze die Breite von Indizes respektive indizierten Attributen möglichst treffend. Es ist unsinnig, Attribute, wie Namen zu indizieren, wenn von 1'000 Einträgen rund 600 mal 'Doe' enthalten ist. Es macht auch wenig Sinn, Geburtsdaten zu indizieren, da es max. 365 Kombinationen gibt. Benutze in solchen Fällen geclusterte Indizes. Essentiell gilt: Eine Suche beginnt im PK respektive im Index, wenn dieser vorhanden ist. Wird hier ein eindeutiges Ergebnis gefunden, wird die Suche beendet, das Tupel direkt angesprungen, die Daten ausgelesen und zurückgegeben. Wird ein Block möglicher Ergebnisse gefunden, werden diese zeilenweise auf Übereinstimmungen "abgeklopft". (Ergo: Je größer der gefundene/vermutete Block ist, desto langsamer die Suche.) Im worst case hast du einen Tabellenscan, der in stark fragmentierten Tabellen schier ewig dauert. Das führt dann auch zum letzten Punkt: - Konsolidierung der Daten bringt oft mehr Performance, als der 3. Index auf eine Tabelle... - Die Anzahl der gleichzeitigen Verbindungen zur Datenbank sollte optimal bemessen werden. (Nicht übermäßig viel, damit das DBMS nicht in Narzismus verfällt, aber auch nicht zu wenige, damit die Benutzer nicht vorher sterben.) - RAM ist das A und O. Je mehr Tabellen gecached (ich liebe dieses Wort:)) werden können, desto weniger Zugriffe auf die Festplatte sind nötig. In diesem Sinne, viel Spaß beim Feintuning, just_me

Low level trigger sind fallback trigger. (... eine abstrakte Antwort auf eine abstrakte Frage. )

... und das Gleiche willst du mit dem MS SQL Server machen? Dann versuch's doch mal spaßeshalber mit dem Query Analyzer...

Stop! Stop! Stop! Das macht <NULL> Sinn. Der Trick ist es doch eigentlich, die Daten mit 100% Sicherheit wiederherstellen zu können, nicht wahr? Warum sollte ich also meine Daten dem Risiko möglicherweise nicht 100% kompatibler Attribute fremder Datenbanken aussetzen? Macht es nicht - rein logisch - viel mehr Sinn, wenn man nicht nur den Inhalt, sondern die "Tüte" gleich mit sichert? Noch dazu, wo dieses "Tüte" kaum Platz in Anspruch nimmt?! MS SQL Server bieten dir verschiedene Optionen, Strategien und Möglichkeiten an, die Ausfälle auf ein absolutes Minimum zu beschränken. Die "einfachste" - und sicherlich von dir gesuchte - Möglichkeit ist es, den Befehl Backup zu verwenden, ein SQL-Script zu erzeugen, und dieses alsTeil eines Auftrages automatisch; oder meinethalben auch per selbstgebastelter Scripte (WSH bietet sich förmlich an) auszuführen. Das so erzeugte Backup, das dann "an der regulären Sicherung vorbei" erstellt wurde, kannst du dir ja ausdrucken und sicherheitshalber auswendig lernen - nur für den Fall, dass es einen Großbrand gibt, und sämtliche Sicherungsmedien das Zeitliche segnen ... Nein, im Ernst: Die Datensicherung erfolgt i.d.R. IMMER zusammen mit dem Container. Alles andere ist zu viel Gottvertrauen. Stelle dir doch mal vor, deine Datenbank reisst die Hufe hoch, ist nicht mehr restaurierbar, und du solltest anhand der vorhandenen Daten die du als reines .sql-script á là "INSERT INTO table1 (feld1, feld2, feld3) VALUES (wert1, wert2, wert3)" vorliegen hast, bestimmen, ob "feld1" nun ein varchar(75) oder doch eher ein varchar(60) ist. Kein Problem, sagst du!? Wen interessiert es, wenn die Daten sowieso nur maximal 50 Zeichen lang zu sein scheinen!? Nun, i.d.R. gibt es Anwendungen, die diese Daten schreiben, und diese erwarten nun einmal fest definierte Attribute, da wäre jede noch so kleine Änderung schlicht tödlich ... zumindest aber verdammt riskant. Und was die "SQL Server Version" angeht: Ich weiß nicht, wer dir diesen Bären aufgebunden hat, aber in jedem Fall kannst du ihm/ihr einen schönen Gruß bestellen. Wenn du so leicht zu foppen bist, dann muss die Arbeit mit dir recht lustig sein. Das Backup ist WEDER an einen bestimmten Server (was purer Wahnsinn wäre), NOCH an eine bestimmte Version gebunden. Letzteres gilt natürlich eingeschränkt, denn rückwärtige Inkompatibilitäten sind nicht immer vollständig auszuschließen, aber die Wahrscheinlichkeit, dass ihr nicht gerade 3 oder 4 Generationen an DBMS überspringt ist doch wohl tendenziell eher als hoch einzustufen, oder? Und falls du all das trotzdem noch als zu unsicher empfindest, dann lass dich doch einfach mal von den Data Transformation Services (DTS) überraschen. Das Festlegen einer automatisierten/manuell gestarteten Aktion in Kombination mit diesen DTS erlaubt dir, mit wenigen Klicks/Befehlszeilen alle beliebigen Daten aus beliebigen Quellen in beliebige Daten beliebiger Ziele zu schreiben. Das Erstellen von .csv, .xls, .mdb, und und und -Dateien gehört für die DTS zu den eher kleinen Übungen.

Einmal vom rein logischen Standpunkt betrachtet, sieht die Frage irgendwie drollig aus: Die Aufgabe des Administrators ist es nun einmal - folgt man seiner sicherlich nicht zufällig gegebenen Berufsbezeichnung -, zu administrieren, also zu beaufsichtigen, zu kontrollieren und zu pflegen. Dazu gehört der entsprechende Verantwortungsbereich, der durch rechtliche und technische Rahmenbedingungen definiert wird. Letztlich ist es also pures Vertrauen, wenn der Admin seiner Pflicht zur Kontrolle nicht oder nur unvollständig nachkommt. (Gewisse Aufgaben werden aufgrund der Fülle verteilt - Beispiel: Forenmoderation -, aber auch dafür zeichnet der Admin in letzter Instanz verantwortlich.) Es stellt sich also weniger die Frage, ob der Admin latent voyeuristische Tendenzen hat, wenn er solche Sachen macht, wie private messages (PN) zu lesen (besser wäre wohl angesichts der Fülle: stichprobenartig zu kontrollieren.); als vielmehr die Frage, warum er es nicht macht und oder machen sollte?! Dass aber auch diese Aufgabe vertraulichen Charakter hat, beweist dieses schlechtestmögliche Beispiel: Persönliche Nachrichten sind juristisch vertraulichen Gesprächen gleichgesetzt. Die Veröffentlichung - auch auszugsweise - ohne Einverständnis aller beteiligten Parteien verletzt private Rechte, welche durch BGB, TKG, TDDSG und BDSG abgesichert sind. (Dies gilt auch dann, wenn die PN's strafrechtlich relevanten Inhalt beherbergen würden. Sollte dies der Fall sein, ist der Administrator berechtigt/verpflichtet, Anzeige bei den verantwortlichen Behörden zu erstatten. Er ist jedoch IN KEINEM FALL befugt, Teile und/oder vollständige PN's öffentlich zugänglich zu machen.) Insbesondere als Bürger der EU wäre ich also zumindest rechtlich in der Lage, den Administrator respektive die entsprechenden Verantwortlichen nach einem solchen Vorfall auf Schadenersatz zu verklagen. (Und dies unbeachtet der Tatsache, ob es moralisch vertretbar wäre, die PN's zu "Beweiszwecken" zu veröffentlichen, oder eben nicht.)

Wenn du eine Tabelle haben willst, welche die Daten für eine eigene Formatierung sammelt, dann versuch's mal mit: -- temporäre Tabelle als Übersicht SELECT sl.[kundenname], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 1 AND sl.uid = uid) AS [Januar], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 2 AND sl.uid = uid) AS [Februar], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 3 AND sl.uid = uid) AS [März], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 4 AND sl.uid = uid) AS [April], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 5 AND sl.uid = uid) AS [Mai], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 6 AND sl.uid = uid) AS [Juni], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 7 AND sl.uid = uid) AS [Juli], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 8 AND sl.uid = uid) AS [August], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 9 AND sl.uid = uid) AS [September], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 10 AND sl.uid = uid) AS [Oktober], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 11 AND sl.uid = uid) AS [November], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = 12 AND sl.uid = uid) AS [Dezember], (SELECT COUNT(zugriffsdatum) FROM shopzugriff WHERE sl.uid = uid) AS [Gesamt] FROM shoplogin AS sl -- Wenn das Jahr uninteressant ist, können alle Zeilen ab hier entfernt werden INNER JOIN shopzugriff AS sz ON sl.uid = sz.uid WHERE DATEPART(year, sz.zugriffsdatum) = 2004 -- das Jahr kann geändert werden Die von dir gewünschte Ausgabe kann mit dem folgenden script erreicht werden:DECLARE @kundenname VARCHAR(25) DECLARE @uid INT DECLARE @count INT DECLARE @datum DATETIME DECLARE @jahr INT SET @jahr = 2004 -- !!! hier das gewünschte Jahr eintragen !!! DECLARE kunden CURSOR SCROLL FOR SELECT uid, kundenname FROM shoplogin OPEN kunden FETCH NEXT FROM kunden INTO @uid, @kundenname SET @datum = '01/01/'+CAST(@jahr AS char(4)) WHILE @@FETCH_STATUS = 0 BEGIN SELECT @count = COUNT(zugriffsdatum) FROM shopzugriff WHERE DATEPART(month, zugriffsdatum) = DATEPART(month, @datum) AND DATEPART(year, zugriffsdatum) = DATEPART(year, @datum) AND uid = @uid --IF @count > 0 -- !!! diese Zeile aktivieren, wenn nur Ausgaben für Zugriffe interessant sind !!! BEGIN PRINT '' PRINT '' PRINT 'Kunde: ' + @kundenname PRINT '------------------' PRINT '' PRINT 'Monat | Anzahl Zugriffe' PRINT '-----------------------' PRINT DATENAME(month, @datum) + ' ' + DATENAME(year, @datum) + ' ' + CAST(@count AS varchar(10)) END FETCH NEXT FROM kunden INTO @uid, @kundenname IF @@FETCH_STATUS <> 0 BEGIN SET @datum = DATEADD(month, 1, @datum) IF DATEPART(year, @datum) <> @jahr BEGIN BREAK END FETCH FIRST FROM kunden INTO @uid, @kundenname END END CLOSE kunden DEALLOCATE kunden IN NO EVENT SHALL just_me BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF SCRIPTS, DOCUMENTS, PROVISION OF OR FAILURE TO PROVIDE SERVICES, OR INFORMATION AVAILABLE FROM HIM.

@jaraz Ach weißt du, ich halte nicht viel von persönlichen Befindlichkeiten. Eben weil man NICHT sicher sein kann, sollte man sich so weit wie irgend möglich absichern, nicht wahr? Alles was existiert, gibt es aus gutem Grunde. Doch wenn es Sicherheit nicht nur eine theoretische Rolle spielt, dann gehe ich ganz gern auf Nummer Sicher. Wenn ich bergsteigen gehe, nehme ich nicht die billigste Wäscheleine, weil ich dem Strick mein Leben anvertrauen muss; wenn ich ein Auto kaufe, achte ich darauf, dass es einige Features, wie Airbags, ABS, etc. besitzt; wenn ich mit dem Fallschirm abspringen will, habe ich ein Notsystem dabei, wenn ich ... hey, fällt dir etwas auf? Sobald es um "persönliche Sicherheit" geht, sind wir ganz offensichtlich recht gründlich; oder würdest du ruhigen Gewissens deinen Fallschirm im Grabbelmarkt kaufen? Warum sollte ich also nicht auch in den mir anvertrauten Dingen eine gewisse (ja, redundante) Sicherheit walten lassen? Eben! Genau das meine ich. Wenn "mein" System bei der Ausführung einer Aufgabe scheitert - und dabei ist es vollkommen gleichgültig, wann, warum, wie und was eintritt, dann werde ich benachrichtigt. Das will und kann ich nicht missen. Ich kann es mir schlicht nicht leisten, darauf zu hoffen, dass schon alles gut gehen wird... Yep. Zweifellos. Doch was du hier ansprichst, ist MENSCHLICHES Versagen. Dagegen hilft nur eine Schrotflinte - oder wahlweise die Androhung persönlicher Haftung. (Stell' dir mal vor, dein Chef würde sagen: "Hey, es ist mir egal, welche Systeme Sie einsetzen, aber ich mache Sie persönlich für eventuelle Verluste haftbar."; was würdest du nehmen, um Unternehmensdaten zu sichern? MySQL? Oracle? MS? DB2? Kombinationen? In jedem Fall würdest du nicht halb so "leichtsinnig" sein, wenn es dein Hintern wäre, der hinhalten müsste, oder?! ) Aber genug davon. Lass' uns mal überlegen, warum die Daten nicht geschrieben wurden, und warum keine entsprechende Sicherheitsmeldung kam.

Das ist doch mal ein wirklich interessantes Problem. Der Haken: MySQL würde ich nicht gerade für mein Steckenpferd halten, und von FreeBSD dachte ich bis dato, es seien Cornflakes... Aber ok, vielleicht hast du ja ein paar Antworten für mich. Frage I: Wie groß dürfen Daten-Dateien unter FreeBSD 4.2 maximal sein? 2GB, 4GB, ... mehr? MySQL mag ja Dateigrößen von mittlerweile einigen TB verkraften, aber schafft es das BS auch? Frage II: Ich kenne mich mit MySQL zu wenig aus - und habe ganz offensichtlich dringenden Nachholebedarf. Flushed MySQL die Daten nicht nach einer festgelegten Zeitspanne und/oder Datengröße? Wenn ja, warum gab es keine Fehlermeldung, wenn die entsprechenden Updates, etc. fehlgeschlagen sind? Frage III: Soweit ich gelesen habe, gibt es mit FreeBSD unterhalb von Version 4.4 Probleme, wenn das MySQL-DBMS versucht, multiple CPU's zu nutzen ... Liegt hier der Hund begraben? Referenzen: www.freebsdforums.org www.bitmechanic.com www.mysql.com <agitationsmode> Ich stelle mir gerade vor, was in einer echten Produktivumgebung für Schaden entstehen könnte, wenn man MySQL benutzen würde. Drei Wochen Arbeit im Nirvana ... 'luja, soag i, 'luja! Sparsamkeit hin, Sparsamkeit her. Nicht umsonst heißt es wohl: Wer billig kauft, kauft zweimal. Nein, im Ernst: Ein DBMS, das bei Fehlern - und JEDER nicht vollständig erfolgreich ausgeführte Auftrag ist ein Fehler - nicht rummeckert, ist mir suspekt. ICH würde meinem Chef bei dieser Gelegenheit vorrechnen, wie viel man beim Erwerb eines professionellen Spielzeugs, wie Oracle's oder MS's DB-Server, sparen könnte, falls dieser Fehler noch einmal auftritt, wenn 20 oder 30 Leute nur eine einzige Woche nicht bemerken, dass da etwas faul ist. Dann fehlen die Produktivergebnisse einer ganzen Arbeitskraft für ein komplettes Jahr ... + mindestens 75.000 EUR Gehalt. (Ganz zu schweigen von den "Randverlusten", wie entgangener Umsatz, etc. Dafür könnte ich mir eine ganze technische Spielwiese finanzieren. Und das alles nur, weil mein Chef für seine Armbanduhr mehr bezahlen wollte, als für das Herz seines Unternehmens? </agitationsmode>

Sun's US Training und SUN Educational Services, Oracle University, Borland und Microsoft stellen sicher einige der bekanntesten Zertifizierungsprogramme für Softwareentwickler, ~-Architekten, ~-Designer, Analytiker und andere ... Ein Titel als XML Master in den Stufen basic und professional ist ebenso möglich, wie verschiedene Produkt-Zertifizierungen bei Symantec und anderen ... Es gibt, um es mit einem Wort zu sagen, mittlerweile mehr Zertifikate als Menschen auf dieser Welt. Suche dir einfach die aus, von denen du meinst, dass sie dich glücklich machen, und/oder in deinem weiteren Leben helfen könnten, und versuche, dich unbeirrt in das Abenteuer (und für einige scheint es tatsächlich eins zu sein) Lernen zu stürzen. Wenn du Fragen hast, wende dich - mehr oder weniger - vertrauensvoll an Prometric oder VUE, die soetwas ähnliches wie ein "weltweites Zertifizierungs-Oligopol" halten. Dort wird man dir sagen können, welche Zertifikate momentan besonders beliebt sind, wo du Prüfungen ablegen kannst, wer aus- respektive weiterbildet, und ... und ... und ....