UNIQUE mit PRIMARY (D00fe Hausaufgaben!!)

[AhANiBoy]

hi

Falls sich wer über die vielen MySQL Postings wundert:
Ich mache gerade Hausaufgaben! :|
Und das um 3:54 :-(

Normalerweise sieht mein CREATE TABLE Syntax in etwa so aus:

CREATE TABLE test (
     id int(10) NOT NULL auto_increment,
     foo varchar(20) NOT NULL,
     bar varchar(20) NOT NULL,
     PRIMARY KEY  (id),
     UNIQUE KEY id (id)
     );

Unser Professor hat das auch immer so verlangt.

Nun habe ich aber gehört dass UNIQUE KEY id (id) angeblich
unnötig ist,  wenn PRIMARY KEY gesetzt ist,
weil es dann automatisch UNIQUE ist.
Was ist nun richtig?
Eventuell wäre UNIQUE INDEX dann richtiger?
Oder auch einfach nur UNIQUE...

Schönen Tag noch wünscht
Euer AhANiBoy

PS.: Ich hab immer noch nicht gerafft was der Unterschied zwischen
     UNIQUE indexname (foo,bar)  und UNIQUE KEY indexname (foo,bar)
     sowie UNIQUE INDEX indexname (foo,bar)  ist...
     Falls wer dazu noch eine Erklärung für mich hat ist das toll.

[Christian Kruse]

你好 AhANiBoy,

Falls sich wer über die vielen MySQL Postings wundert:
Ich mache gerade Hausaufgaben! :|
Und das um 3:54 :-(

Das naechste mal einfach im selben Thread bleiben...

Nun habe ich aber gehört dass UNIQUE KEY id (id) angeblich
unnötig ist,  wenn PRIMARY KEY gesetzt ist,
weil es dann automatisch UNIQUE ist.
Was ist nun richtig?

Ein PRIMARY KEY ist per Definition Unique, der zusaetzliche
UNIQUE-Constraint ist voellig ueberfluessig.

PS.: Ich hab immer noch nicht gerafft was der Unterschied zwischen
     UNIQUE indexname (foo,bar)  und UNIQUE KEY indexname (foo,bar)
     sowie UNIQUE INDEX indexname (foo,bar)  ist...
     Falls wer dazu noch eine Erklärung für mich hat ist das toll.

UNIQUE und UNIQUE INDEX sind dasselbe, das INDEX dabei ist optional.
UNIQUE KEY hab ich noch nirgends gelesen.

再见,
克里斯蒂安

[AhANiBoy]

hi Christian Kruse!

Noch einmal Danke für deine schnelle Hilfe!
Dieses Forum hier ist echt TOP!
Hoffentlich kann ich bald gleich gut helfen wir ihr'z!

Wg. UNIQUE und UNIQUE INDEX ... wenn da KEIN Unterschied besteht,
wofür gibt es dann beide?
Darf ich bei beiden einen Index-Namen anführen?

UNIQUE indexname (first, last)
UNIQUE INDEX indexname (first, last)

Dankende Grüße,
AhANiBoy

[AhANiBoy]

hi

Diesmal bleib ich im gleichen Thread.

Als ich eben meine DB dump'te um meine Hausaufgaben in die
Schule mitnehmen zu können kam unter anderem Folgendes raus:

CREATE TABLE pupil (
  id int(10) NOT NULL auto_increment,
  klasse varchar(250) NOT NULL default '',
  schule varchar(250) NOT NULL default '',
  info text NOT NULL,
  PRIMARY KEY  (id),
) TYPE=MyISAM;

Das  TYPE=MyISAM  habe ich selbst sicherlich nicht da hin geschrieben.
Das kam von selbst einfach so!

Ist es falsch wo es ist?  (ausserhalb der () Klammern)
Was bedeutet es überhaupt?
Das MySQL-Manual sagt mir dass es viele verschiedene Types gibt,
aber wie soll ich wissen welche Types ich haben will?

Es soll nur Text erfasst werden.
Von wenig bis viel Text,  teilweise sehr viel Text.

In einer ANDEREN Tabelle sollen auch Bilder gespeichert werden,
falls das was zur Sache tut!

Schönen Tag noch wünscht
Euer AhANiBoy

[Christian Kruse]

你好 AhANiBoy,

Diesmal bleib ich im gleichen Thread.

Brav ;-)

CREATE TABLE pupil (
  id int(10) NOT NULL auto_increment,
  klasse varchar(250) NOT NULL default '',
  schule varchar(250) NOT NULL default '',
  info text NOT NULL,
  PRIMARY KEY  (id),
) TYPE=MyISAM;

Schoener sieht es so aus:

  
CREATE TABLE pupil (  
  id int(10) NOT NULL auto_increment,  
  klasse varchar(250) NOT NULL default '',  
  schule varchar(250) NOT NULL default '',  
  info text NOT NULL,  
  PRIMARY KEY  (id),  
) TYPE=MyISAM;  

Das  TYPE=MyISAM  habe ich selbst sicherlich nicht da hin geschrieben.
Das kam von selbst einfach so!

Ja, du hast es weggelassen und in der von dir benutzten Version ist MyISAM
das Standard-Format fuer Tabellen. Das koennte aber aendern, also schreibt
MySQL-Dump es extra dahin.

Ist es falsch wo es ist?  (ausserhalb der () Klammern)

Nee.

Was bedeutet es überhaupt?

Es gibt verschiedene Tabellen-Typen, eine dieser Typen ist MyISAM.

Das MySQL-Manual sagt mir dass es viele verschiedene Types gibt,
aber wie soll ich wissen welche Types ich haben will?

Das haengt vom Einsatzgebiet ab. Bei BDB wird die Tabelle in einer
Berkeley-DB gespeichert, die eignet sich sehr gut fuer Key-Value-Zuordnungen, ausserdem kann BDB transaktionssicheres Pagelocking. Genauere
Infos findest du hier:

http://dev.mysql.com/doc/mysql/de/bdb-characteristics.html

Bei HEAP wird die Tabelle vollstaendig im Arbeitsspeicher gehalten,
dadurch wird der Zugriff zwar sehr schnell, aber dafuer darf sie auch nicht
zu gross werden (weisst schon, RAM gibts nur wenig). Ausserdem gehen alle
Daten verloren, wenn MySQL abstuerzt. Genauere Infos findest du hier:

http://dev.mysql.com/doc/mysql/de/heap.html

ISAM ist eine B-Baum-Tabellenformat, was ein B-Baum ist, kannst du hier
nachlesen:

http://de.wikipedia.org/wiki/B-Baum

Allerdings ist das ISAM-Format deprecated, weil MyISAM im Grunde dasselbe
macht nur besser. Genauere Infos findest du hier:

http://dev.mysql.com/doc/mysql/de/isam.html

InnoDB ist Transaktionssicher (Commit, Rollback, Reparatur) und kann
Zeilen-Locking, deshalb ist es gut geeignet fuer grosse Datenmengen.
Naehere Infos gibt es hier:

http://dev.mysql.com/doc/mysql/de/isam.html

Mit MERGE und MRG_MYISAM kann man mehrere aequivalente (sic!)
MyISAM-Tabellen zu einer “virtuellen,” grossen Tabelle zusammenfassen.
Dazu muessen die Tabellen aber wirklich identisch sein! Naehere Infos gibts
hier:

http://dev.mysql.com/doc/mysql/de/merge.html

MYISAM ist, das hatte ich ja schon geschrieben, die Neu-Entwicklung des
ISAM-Typs. Naehere Infos gibts hier:

http://dev.mysql.com/doc/mysql/de/myisam.html

In einer ANDEREN Tabelle sollen auch Bilder gespeichert werden,
falls das was zur Sache tut!

Bilder solltest du nie in einer Datenbank speichern, hoechstens die Pfade
dazu... Bilder in einer DB machen sie gross und langsam.

再见,
克里斯蒂安

[AhANiBoy]

hi Christian!

Du bist ja besser als unser Lehrer...!
Hast Du Dir schonmal überlegt zu unterrichten?

Deine Antwort ist echt genial und umfangreich!
Ich hab jetzt mal in alles hineingeschnuppert.

Meine Frage an Dich (als Programmierer, wie ich vermute)
ist ganz einfach:  Welches Type soll ICH verwenden?

Es fällt mir als Beginner sehr schwer das (trotz Hintergrundinfos)
zu entscheiden.  Bitte sag mir was ich nehmen soll.
Es soll sicher sein und einfach funktionieren,
ohne Probleme zu machen.

Irgendwie gibt es mir ein Gefühl von Sicherheit,
MyISAM zu verwenden,  weil es MySQL als Default Wert nimmt.
Vielleicht ist aber dennoch was anderes besser.

Bitte berate mich aus der sicht des Programmierers.
Ich vermag trotz der vielen Infos das nicht alleine zu entscheiden,
Du weisst aus der Praxis sicher besser was gut ist!

Dankende Grüße,
AhANiBoy

[Christian Kruse]

你好 AhANiBoy,

Meine Frage an Dich (als Programmierer, wie ich vermute)
ist ganz einfach:  Welches Type soll ICH verwenden?

Der, der deinen Beduerfnissen am ehesten nahe kommt...

Bitte berate mich aus der sicht des Programmierers.
Ich vermag trotz der vielen Infos das nicht alleine zu entscheiden,
Du weisst aus der Praxis sicher besser was gut ist!

Anfaenger brauchen eigentlich nie etwas anderes als MyISAM.

再见,
克里斯蒂安

[Christian Kruse]

你好 AhANiBoy,

Wg. UNIQUE und UNIQUE INDEX ... wenn da KEIN Unterschied besteht,
wofür gibt es dann beide?

Um dem Standard naeher zu bleiben. AFAIK schreibt der SQL99-Standard
UNIQUE INDEX vor. Der Gedankengang war wohl: “Das ist zu lang!”, also
haben sie es dann optional gemacht.

Darf ich bei beiden einen Index-Namen anführen?

Ja.

再见,
克里斯蒂安

[Ilja]

yo,

UNIQUE und UNIQUE INDEX sind dasselbe, das INDEX dabei ist optional.

wäre dies der fall, würde auch immer dasselbe passieren. meiner meinung gibt es aber unterschiede. ein unique contraint benutzt nur einen index, um diesen constraint schneller ausführen zu können. demzufoge legt es gleichzeitig einen index an, falls keiner vorhanden ist. ist aber bereits in ein index auf dieser spalte (spalten) vorhanden, wird kein weiterer index angelegt, sondern der schon vorhandene benutzt. mit anderen worten, ein unique contraint kann einen index nach sich ziehen, muss aber nicht. ein unique index wird aber meiner meinung nach immer einen weiteren index erzeugen, egal ob schon einer vorhanden ist oder nicht. demzufolge wäre es nicht dassselbe.

Ilja

[Christian Kruse]

你好 Ilja,

UNIQUE und UNIQUE INDEX sind dasselbe, das INDEX dabei ist optional.

wäre dies der fall, würde auch immer dasselbe passieren. meiner meinung
gibt es aber unterschiede. ein unique contraint benutzt nur einen index,
um diesen constraint schneller ausführen zu können. demzufoge legt es
gleichzeitig einen index an, falls keiner vorhanden ist. ist aber
bereits in ein index auf dieser spalte (spalten) vorhanden, wird kein
weiterer index angelegt, sondern der schon vorhandene benutzt.

Wo hast du diese Information her? Im MySQL-Handbuch steht das nicht. Und
um es mal so zu sagen: deine Aussage ist nicht haltbar, aus mehreren
Gruenden.

1. Habe ich davon nichts im Handbuch gefunden
2. Habe ich nichts gefunden, was im Sourcecode darauf hinweist, im
      Gegenteil, wenn ich das richtig verstanden habe, ist das INDEX einfach
      nur optional.
3. Habe ich es ausprobiert: lege eine Tabelle so an:

  
create table test (  
  id int(10) not null primary key auto_increment,  
  foo varchar(120),  
  UNIQUE INDEX (foo)  
);  

Wenn ich jetzt mysqldump darueberlaufen lasse, kommt das bei raus:

  
CREATE TABLE test (  
  id int(10) NOT NULL auto_increment,  
  foo varchar(120) default NULL,  
  PRIMARY KEY  (id),  
  UNIQUE KEY foo (foo)  
) TYPE=MyISAM;  

Tabelle droppen und neu anlegen, diesmal so:

  
create table test (  
  id int(10) not null primary key auto_increment,  
  foo varchar(120),  
  UNIQUE (foo)  
);  

Jetzt wieder mysqldump drueberlaufen lassen, dann kommt das dabei raus:

  
CREATE TABLE test (  
  id int(10) NOT NULL auto_increment,  
  foo varchar(120) default NULL,  
  PRIMARY KEY  (id),  
  UNIQUE KEY foo (foo)  
) TYPE=MyISAM;  

Man beachte das UNIQUE KEY foo (foo)!

Alles in allem (Handbuch, Code, Tests): deine Aussage ist Quatsch, das
INDEX ist einfach nur optional.

再见,
克里斯蒂安

[Ilja]

yo,

Alles in allem (Handbuch, Code, Tests): deine Aussage ist Quatsch, das

sicherlich kann ich mich irren, keine frage. aber meine aussage war, ein unique contraint auf eine spalte, die schon einen index besitzt, wird keinen zusätzlichen index erzeugen. und das setzt vorraus, dass es eine tabelle schon gibt. deine test liefen aber alle darauf hinaus, tabellen zu erzeugen.

Ilja

[Christian Kruse]

你好 Ilja,

sicherlich kann ich mich irren, keine frage. aber meine aussage war, ein
unique contraint auf eine spalte, die schon einen index besitzt, wird
keinen zusätzlichen index erzeugen. und das setzt vorraus, dass es eine
tabelle schon gibt.

Das hat wenig mit dem zu tun, was du anfangst gesagt hast, aber sagen wir
es so: ein UNIQUE constraint zieht _immer_ einen Index nach sich. Egal,
ob ueber die Spalte bereits ein Index ist oder nicht. Bei CREATE INDEX
ist das INDEX gar nicht optional... da heisst es:

CREATE [UNIQUE|FULLTEXT] INDEX

deine test liefen aber alle darauf hinaus, tabellen zu erzeugen.

Das ist quatsch, lediglich mein dritter Test lief darauf hinaus. Weder
Manual noch Sourcecode geben dir recht.

再见,
克里斯蒂安

[Ilja]

yo Christian,

Das hat wenig mit dem zu tun, was du anfangst gesagt hast

nun, ich kann eigentlich keinen inhaltlichen unterschied in den aussagen finden. in beiden habe ich gesagt, ein Unique contraint kann einen index nach sich ziehen, muss aber nicht, wenn schon bereits einer vorhanden ist.

es so: ein UNIQUE constraint zieht _immer_ einen Index nach sich. Egal,
ob ueber die Spalte bereits ein Index ist oder nicht.

dann wäre meine frage, welchen zwecke sollte ein zusätzlicher index haben, der über die gleiche spalte geht ? dann hätten wir zwei indexe, die beide "gepflegt" werden wollen, aber keinen zusatznutzen bringen.

Das ist quatsch, lediglich mein dritter Test lief darauf hinaus. Weder
Manual noch Sourcecode geben dir recht.

nun ja, ich würde nachschlagen im manuel und sourcecode nicht als test bezeichnen. wie auch immer, ich meinte dein drittes argument. da habe ich mich dann falsch ausgedrückt.

Ilja

[Christian Kruse]

你好 Ilja,

Das hat wenig mit dem zu tun, was du anfangst gesagt hast

nun, ich kann eigentlich keinen inhaltlichen unterschied in den aussagen
finden. in beiden habe ich gesagt, ein Unique contraint kann einen
index nach sich ziehen, muss aber nicht, wenn schon bereits einer
vorhanden ist.

Im ersten Post ging es um die Unterschiede zwischen CREATE TABLE ...
UNIQUE () und CREATE TABLE ... UNIQUE INDEX ().

es so: ein UNIQUE constraint zieht _immer_ einen Index nach sich. Egal,
ob ueber die Spalte bereits ein Index ist oder nicht.

dann wäre meine frage, welchen zwecke sollte ein zusätzlicher index
haben, der über die gleiche spalte geht ?

Was weiss ich -- ich wuerde einen zusaetzlichen Index nicht anlegen. Es
gibt bei MySQL halt kein reines UNIQUE-Constraint (wie das bei anderen
DBMS aussieht weiss ich nicht), sondern nur einen Index-Typ UNIQUE. Und
wenn du einen UNIQUE-Constraint haben willst, musst du entweder den alten
Index aendern oder einen neuen Index anlegen. Wie gesagt, der Befehl sagt
es schon: CREATE UNIQUE INDEX. Eine andere Methode
nachtraeglich einen UNIQUE-Constraint auf eine (oder mehrere) Spalte(n) zu
legen gibt es meines Wissens nach nicht.

再见,
克里斯蒂安

[Ilja]

yo Christian,

Im ersten Post ging es um die Unterschiede zwischen CREATE TABLE ...
UNIQUE () und CREATE TABLE ... UNIQUE INDEX ().

ich habe das so interpretiert, dass es generell um den unterschied ging und nicht nur bei create table, zumindestenz war bei deiner aussage nichst zu finden, dass sich das nur auf CREATE bezieht.

Was weiss ich -- ich wuerde einen zusaetzlichen Index nicht anlegen.

ich kenne auch keinen guten grund. es scheint keinen sinn zu machen.

CREATE UNIQUE INDEX. Eine andere Methode
nachtraeglich einen UNIQUE-Constraint auf eine (oder mehrere) Spalte(n) zu
legen gibt es meines Wissens nach nicht.

http://dev.mysql.com/doc/mysql/en/alter-table.html

Ilja

[Christian Kruse]

你好 Ilja,

Im ersten Post ging es um die Unterschiede zwischen CREATE TABLE ...
UNIQUE () und CREATE TABLE ... UNIQUE INDEX ().

ich habe das so interpretiert, dass es generell um den unterschied ging
und nicht nur bei create table, zumindestenz war bei deiner aussage
nichst zu finden, dass sich das nur auf CREATE bezieht.

Eh, hu? Es ging ganz klar um CREATE TABLE-Syntax, denn das war doch das,
was der OP gefragt hat...

Was weiss ich -- ich wuerde einen zusaetzlichen Index nicht anlegen.

ich kenne auch keinen guten grund. es scheint keinen sinn zu machen.

Nein, ich meinte: ich wuerde keinen zusaetzlichen UNIQUE-Index anlegen,
ich wuerde entweder einen UNIQUE-Index anlegen oder einen “normalen” Index.

CREATE UNIQUE INDEX. Eine andere Methode
nachtraeglich einen UNIQUE-Constraint auf eine (oder mehrere) Spalte(n)
zu legen gibt es meines Wissens nach nicht.

http://dev.mysql.com/doc/mysql/en/alter-table.html

Ja, ok, aber bei ALTER TABLE passiert dasselbe wie bei CREATE TABLE.

Whatever, in der gesamten MySQL-Dokumentation ist immer nur von
UNIQUE-Indizes die Rede. Sorry, aber deine Aussage wird immer weniger
sinnvoll. Wo hast du das denn jetzt her?

再见,
克里斯蒂安

[Ilja]

yo,

Eh, hu? Es ging ganz klar um CREATE TABLE-Syntax

nun, scheinbar so ganz klar war das zumindestenz nicht für mich. schließlich werden die schlüsselbegriffe wie UNIQUE oder UNIQUE INDEX nicht nur bei der CREATE TABLE syntax verwendet.

wie auch immer, meine aussagen bezogen sich darauf, dass eine tabelle bereits vorhanden ist, da ohne eine tabelle auch kein index vorhanden sein kann.

Ja, ok, aber bei ALTER TABLE passiert dasselbe wie bei CREATE TABLE.

gerade das ist meiner meinung nach nicht der fall. bei der create table anweisung wird mit der unique spalte auch ein index auf die entsprechende tabelle erzeugt werden (kann ja keine index vorhanden sein). bei einem ALTER sollte das dbms aber genau das nicht tun, wenn diese spalte schon einen unique index besitzt. ein UNIQUE INDEX wird meiner meinung nach aber immer erzeugt, egal ob schon ein index auf die spalte vorhanden ist oder nicht. aber ich glaube, wir drehen uns im kreise...

Ilja

[Christian Kruse]

你好 Ilja,

Eh, hu? Es ging ganz klar um CREATE TABLE-Syntax

nun, scheinbar so ganz klar war das zumindestenz nicht für mich.
schließlich werden die schlüsselbegriffe wie UNIQUE oder UNIQUE INDEX
nicht nur bei der CREATE TABLE syntax verwendet.

Ja, aber der OP hat nach CREATE TABLE gefragt :)

Ja, ok, aber bei ALTER TABLE passiert dasselbe wie bei CREATE TABLE.

gerade das ist meiner meinung nach nicht der fall. bei der create table
anweisung wird mit der unique spalte auch ein index auf die
entsprechende tabelle erzeugt werden (kann ja keine index vorhanden
sein). bei einem ALTER sollte das dbms aber genau das nicht tun, wenn
diese spalte schon einen unique index besitzt. ein UNIQUE INDEX wird
meiner meinung nach aber immer erzeugt, egal ob schon ein index auf die
spalte vorhanden ist oder nicht. aber ich glaube, wir drehen uns im
kreise...

Nein, es wird nicht unterschieden zwischen UNIQUE und UNIQUE INDEX. Wenn
du mir nicht glaubst schau selbst im Sourcecode nach oder probiere es aus.

再见,
克里斯蒂安

[Ilja]

yo,

Nein, es wird nicht unterschieden zwischen UNIQUE und UNIQUE INDEX. Wenn
du mir nicht glaubst schau selbst im Sourcecode nach oder probiere es aus.

mein rechner mit der datenbank steht wieder und ich konnte es ausprobieren. vorher war ich ein wenig auf den trockenen. ich habe alles über phpmyadmin ausprobiert und es wird kein unterschied gemacht. auch bei UNIQUE versucht er jedesmal einen index anzulegen, auch wenn schon ein index vorhanden ist. insofern hattest du recht.

was mir bliebt ist den moralischen raushängen zu lassen, dass solch ein vorgehen meiner meinung nach nicht sehr klug ist. letztlich kommen dann zwei indexe auf der gleichen spalte heraus, was ich ein wenig unnötig finde. ausserdem hat er probleme damit, einen UNIQUE constraint zu erstellen, falls der schon vorhandene index den gleichen namen wie die entsprechende spalte besitzt.

Ilja

[Ilja]

yo,

CREATE TABLE test (
     id int(10) NOT NULL auto_increment,
     foo varchar(20) NOT NULL,
     bar varchar(20) NOT NULL,
     PRIMARY KEY  (id),
     UNIQUE KEY id (id)

ich habe ja bereits schon einmal erwähnt, dass eine primary key zwei eigenschaften besitzt, nämlich not null und unique. demzufolge ist auch dein not null contraints überflüssig.

zum anderen geht dein primary key nur über eine spalte (id). insofern kann man ich auch gleich in der spaltendefinition mit angeben.

CREATE TABLE test2 (
      id int(10) PRIMARY KEY auto_increment,
      foo varchar(20) NOT NULL,
      bar varchar(20) NOT NULL
);

ist dann auch gleich zwei spalten weniger tippen und bewirkt das gleiche.

Ilja

[Ludger]

Hi Ilja,

nur mal interessehalber, schreibst Du auch Datenzugriff oder bist Du aufs relationale Datendesign spezialisiert?

Gruss,
Ludger

[Ilja]

yo Ludger,

nur mal interessehalber, schreibst Du auch Datenzugriff oder bist Du aufs relationale Datendesign spezialisiert?

ich habe die frage nicht ganz verstanden. was genau meinst du ?

Ilja

[Ludger]

Hi,

nur mal interessehalber, schreibst Du auch Datenzugriff oder bist Du aufs relationale Datendesign spezialisiert?

ich habe die frage nicht ganz verstanden. was genau meinst du ?

Hintergrundinfo: http://www.tomjewett.com/dbdesign/dbdesign.php?page=ddldml.php&imgsize=medium

DDL & DML und so

Gruss,
Ludger

[Ilja]

yo,

DDL & DML und so

in aller regel arbeite ich mit beiden formen von befehlen. warum die frage ?

Ilja

[Ludger]

Hi,

DDL & DML und so

in aller regel arbeite ich mit beiden formen von befehlen. warum die frage ?

ich weiss ja nicht genau, was Du machst, hatte aber den Eindruck, dass Du auf DDL (und Serveradministration?) spezialisiert bist und Datenzugriff weniger programmierst, darum die Frage.

Was machst Du eigentlich?

Gruss,
Ludger

[Ilja]

yo,

Was machst Du eigentlich?

das frage ich mich jeden tag. jedenfalls mein zertifikat weisst mich als OCP aus und ich habe da auch noch so einen blauen von microsft als MCP....

Ilja

[Ludger]

Hi,

Was machst Du eigentlich?

das frage ich mich jeden tag. jedenfalls mein zertifikat weisst mich als OCP aus und ich habe da auch noch so einen blauen von microsft als MCP....

nicht ausweichen, MCP bin sogar ich.   ;-)

Gruss,
Ludger

PS: Studi oder Profi?

[Ilja]

yo,

PS: Studi oder Profi?

bin kein leider kein student. ob ich mich schon als vollwertigen profi bezeichnen würde, sicherlich im rahmen meiner möglichkeiten.

Ilja

[Ludger]

Hi,

bin kein leider kein student. ob ich mich schon als vollwertigen profi bezeichnen würde, sicherlich im rahmen meiner möglichkeiten.

und was machst Du so? Sitzt Du nur auf den Datenservern?

Gruss,
Ludger