dr.dimitri

Und wo genau liegt Dein Problem? Was hast Du denn bisher schon gemacht? Dim

Leg eine eigene Spalte an, die dann der Pk wird. Diese Spalte befüllst Du z.B. mit einem Autowert. Eine Tabelle hat immer nur einen PK. Ein PK muss immer ein rein technisches Feld ohne jeglichen fachlichen Bezug sein, ansonsten kannst in größere Probleme laufen. Du kannst einen PK aus mehreren Feldern zusammensetzen, allerdings deutet das wiederum meistens auf ein Tabellendesignproblem hin. Grundregel: Falls ein PK benötigt wird, dann ein eigenes Feld dafür anlegen und nicht andere Felder dafür missbrauchen. Dim

Eigentlich keine. Wenn die Daten ordentlich exportiert werden (z.B. in eine Textdatei) dann können sie mit geeigneten Mitteln auch in die MSSQL DB importiert werden. Wo siehst Du hier Probleme? Dim

Einfach so: Update deine_tabelle set emaillink=replace (emaillink,'PROD','TEST'); commit; Fertig. Da brauchst kein PL/SQL. Dim PS: Die Spalte heißt nicht wirklich e-maillink (also mit Bindestrich) oder?

Hier wär ein Beispiel. Muss man eben für mysql entspreched vereinfachen/anpassen. Dim

Ich seh leider keine Einträge, die doppelt sind und die nach Anlage des Index nicht mehr rein dürfen. Die Kombinationen sind alle eindeutig. Dim

Wieso verwendest Du ein GROUP BY und ein LIKE? Beides ist hier unnötig: SELECT versicherungsnehmer FROM tbl_besitzer WHERE NOT versicherung ='AOK' Allerdings hätte es auch in Deiner ursprünglichen Form funktieren müssen. Bist Du sicher, dass AOK bei Julius korrekt in der DB steht? Nicht etwa Aok u.ä? Dim

Im allgemeinen verwendet man dazu auch keinen Trigger, sondern trägt die Daten die man haben möchte selbst ein. Wenn ich einen leeren Eintrag möchte, dann lege ich ihn an - dazu braucht man keinen Trigger. Über mysql_insert_id() bekommst Du die gerade vergebene ID der Tabelle und kannst sie verwenden um die Sicherheitsdaten zu befüllt. Dazu muss man keinen Trigger erstellen und dort irgendwelche Logik verstecken. Dim

Dein Datenmodell ist falsch. Der Benutzer hängt nicht an den Sicherheitsdaten sondern umgekehrt. Also den Verweis zu den Sicherheitsdaten raus aus der Benutzertabelle und statt dessen einen Foreign Key in den Sicherheitsdaten zum Benutzer. Dann hast auch dieses Henne Ei Problem nicht, denn der User wird zuerst angelegt und dann seine Sicherheitsabfragen - so wie man es auch in der Realität erwarten würde. Dim

Das kann ich jetzt nicht ganz nachvollziehen. Kannst Du bitte mal Beispieldaten posten, die die falschen Daten besser erklären? Dim

Hast Du denn alle Spalten befüllt? Falls auch in nur einer der 4 Spalten ein NULL Wert steht, ist er immer ungleich der anderen Zeilen. Die ID könnte man eigentlich auch wieder aus dem Index entfernen, denn hier sorgt eh schon der PK Constraint, dass diese eindeutig ist. Dim

create unique index myunique_ix on automarke(ID, MARKE, HERSTELLER, HERSTELLUNGSLAND) Den Pk solltest Du wieder auf die ID alleine reduzieren. Des weiteren ist ein PK implizit schon NOT NULL. Dim

WHERE [B][COLOR=red]([/COLOR][/B]Thema.Standort = '11' (Standorte immer 2 stellig) OR Thema.Standort = '0' [B][COLOR=red])[/COLOR][/B] (0 steht für übergreifende Themen) Zum einen eine vergessene Klammer, und dann noch das LIKE. Laut Kommentar fehlt ein %: AND Teilnehmer.Abteilung LIKE '110[B][COLOR=red]%[/COLOR][/B]' Dim

Naja auf dem Feld liegt ein NOT NULL Constraint. D.h. entweder der Constraint ist falsch gesetzt und Du musst ihn vorher entfernen (lassen), oder aber es gibt einen guten Grund warum jemand diesen Constraint eingeführt hat und das setzen eines NULL Wertes hätte unerwartete Auswirkungen auf die Anwendung o.ä. Auf jeden Fall sollte man da genauer Nachforschen bevor man den Constraint entfernt. Dim

MSSQL besitzt doch serverseitiges Autocommit. Ist es auf dem einen Server eingeschaltet und auf dem anderen nicht? Laufen beide Vorgänge in einer einzigen Transaktion und wird auf der "langsamen" Maschine nach jedem Insert comittet? Was soll eine Volltextindizierung nutzen? Und vor allem was willst Du indizieren? Liegt die XML Datei in der Datenbank? Dim

Da fallen mir direkt ein paar Sachen ins Auge: 1. Du solltest Dich bei der Tabellenbenennung für den Singular oder den Plural entscheiden, nicht mischen. Ich persönlich bevorzuge den Singular. Also z.B. statt dem Begriff Personalien das was auch drinnen steht also Person. Das aber nur als Vorschlag um die Lesbarkeit zu erhöhen. 2. Das momentane Alter unterliegt doch recht großen Schwankungen. Daher niemals das Alter, sondern immer das Geburtsdatum hinterlegen. 3. Die Tabelle PERSONALIEN ist die übergeordnete Tabelle. Also raus mit dem Feld IDAdresse. Die Beziehungsbeschreibung würde dann lauten: Eine Person hat eine, keine oder mehrere Adressen, eine Adresse ist genau einer Person zugeordnet. In die Tabelle ADRESSE kommt dann das Feld IDPERSONALIEN als Fremdschlüssel rein Damit ist auch Dein Problem erledigt. Du trägst zuerst per PHP die Personendaten ein, dann die Adressdaten und anschließend COMMIT. Ein FK bildet die Beziehung aber von unten nach oben ab, nicht von oben nach unten. D.h. die übergeordnete Tabelle kennt die untergeordnete erstmal nicht, die untergeordnete weiß aber über den Fremdschlüssel welche Tabelle ihr übergeordnet ist. Da hast Du einen ganz großen Denkfehler drinnen, der dann zu Deinem Problem führt. Du hast jetzt eine 1:1 Beziehung. D.h. eine Person hat genau eine Adresse. Sofern das richtig wäre könnte man sich die zweite tabelle auch direkt sparen und alles in einer tabelle zusammenbauen (machen wir aber natürlich nicht, denn wir wollen für eine Person ja auch mehrere Adressen angeben können). Augenscheinlich haben diesen Denkfehler aber wohl mehrere Also ruhig nachmachen. Dim

Naja das Teil ist weit davon entfernt perfekt zu sein: 1. Fehlerbehandlung. Der Aufrufer kriegt davon nichts mit und es wird einfach weitergemacht, des weiteren verschwindet die Meldung einfach auf der Konsole. Eine "perfekte" Methode würde das via Log4J wegschreiben. 2. Ressourcen werden nicht im finally Block freigegeben. Je nach Implementierung des JDBC Treibers kann das dann irgendwann zu Problemen führen, vor allem, wenn an anderer Stelle auch so schludrig mit DB-Ressourcen umgegangen wird. 3. Bei einer reinen Existenzprüfung sollte immer ein COUNT verwendet werden anstatt den kompletten Datensatz zurückzuliefern. Das ist deutlich performanter. Insb. wenn auf die Maschine mal Last kommen sollte, wirkt sich das positiv aus. Die while Schleife kann man sich in diesem Fall auch sparen. Das PrepStatement wurde ja schon erwähnt. Als weitere Verbesserung wäre noch anzubringen, dass Methoden und Variablennamen im allgemeinen mit einem Kleinbuchstaben beginnen. Dim

Das ist schon richtig. Eine andere (kürzere) Form Deiner Abfrage wäre: AND id IN('abc','xxx','xzy') Dim

Letzteres wäre meine Wahl. Bezüglich der Schemate: Ich bin im Schneeflockenschema zuhause. Reine OLAP Systeme habe ich bisher noch nicht designed. Dim

Hmm ich hab die Begriffe so noch nie gehört, gehören wohl eher in die theoretische Abteilung Das ist der Normalfall. Der PK der übergeordneten Tabelle wird als FK in der untergeordneten abgelegt. Kann man machen, ich würde aber davon abraten einen PK gleichzeitig auch als FK zu verwenden. Zum einen könnest Du Probleme bekommen, wenn doppelte Einträge vorhanden sind (ein PK ist immer Unique) zum anderen macht es die Sache m.M. nach unübersichtlicher. So knapp sind wir nicht an Spalten und dieses Vorgehen erinnert mich an den Code, den diverse "Gurus" in ihren Programmen hinterlassen (Variablen haben grundsätzlich nur einen Buchstaben, alles was nicht unbedingt sein muss wird weggelassen. Sieht cool aus, kann nur keiner mehr lesen). Wir machen sowas natürlich nicht, sondern legen eine eigene Spalte für den PK an. Da Du hoffentlich für einen PK immer ein rein technisches Feld ohne jeglichen fachlichen Bezug verwendet hast, kommst Du überhaupt nicht in diese Verlegenheit. Verwende als PK immer eine laufende Nummer (generiert von der DB per Sequenze, AutoInc) oder eine GUID. Möglich wäre auch, ein per Definition eindeutiges fachliches Feld zu verwenden und dieses in der Tabelle zu doppeln. Beispiel: Die Sozialversicherungsnummer ist eindeutig. Dann hast Du ein Feld ID für den PK und ein Feld SOZVERSNR, welche mit identischen Werten bestückt werden. Kann manchmal ganz nützlich sein, wenn man als Entwickler "weis", dass der PK einen gewissen fachlichen Hintergrund hat. Im Programm selbst wird natürlich nur die SOZVERSNR an die Oberfläche geliefert, die ID wird lediglich im Hintergrund verwendet. Schema? Du meinst den Hersteller? Fast ausschließlich Oracle. Dim

Da gibt es eigentlich keine Balance zu finden. Was gebraucht wird, wird angelegt. Einer Datenbank ist es egal, ob sie 100 oder 120 Tabellen beinhaltet. Das macht auch die Administration nicht einfacher oder schwerer. Das kann man als Lookuptabelle durchaus so machen (um z.B. einen eingegebenen Strassennamen zu prüfen) abspeichern würde ich das aber immer als Klartext in der entsprechenden Tabelle. Sprich Du hast als Stammdaten z.B. eine Tabelle mit PLZ und Strassennamen, eine mit Vorwahlnummern etc. aber wenn der User dann seine Adresse wirklich eingegeben hat, wird der, vorher anhand der Stammtabellen verifizierte Inhalt, im Klartext in die Adresstabelle geschrieben. Speicherplatz ist billig. Eine zu langsame Datenbank nicht. Wieviel GB benötigt man, um 10 Millionen Adressdaten zu speichern? Wenn man mal von, sagen wir 500 Byte pro User ausgeht, dann würden 10 Millionen auf ~5GB kommen - also nix. Wenn ich das jetzt auf 2GB drücken kann, weil ich extrem normalisiert habe, spare ich mir wieviel Euro? Dagegen stehen dann eine deutlich verschlechterte Performance, weil meine SQL Statements für jeden Zugriff noch über weitere Tabellen joinen müssen, ausserdem erhöhter Entwicklungsaufwand, denn jede zusätzliche Tabelle erhöht die technische Komplexität - bei gleicher fachlichkeit des Programms. Grundsätzlich geht man so heran, dass man zuerst mal ein ER-Modell designed, welches die Anforderungen an Daten und Flexibilität erfüllt - dazu ist selbstverständlich eine genaue fachliche Anforderung nötig. Dieses ER-Modell liegt dann in der 3. NF vor. Jetzt beginnt man gezieht zu denormalisieren d.h. Redundanzen einzubauen, um Zugriffe zu beschleunigen und die Entwicklung zu vereinfachen. Das ganze ist natürlich auch Übungssache, wie auch beim Autofahren so wird aus des Modellieren mit der Zeit besser werden (zumindest bei den meisten...) Keine Ahnung. Ich bin nicht mal bei facebook angemeldet geschweige denn, dass ich irgendeine Ahnung von deren Datenmodell hätte. Webdatenbanken sind aber allgemein eher stärker denormalisiert, da es im Netz nix schlimmeres gibt als eine Wartezeit länger als 2 Sekunden. Dazwischen gibt es selbstversändlich noch Proxies, die Abfragen cachen, Loadbalancer etc. etc. um die Last auf die Datenbanken so gering wie möglich zu halten. Das Problem hast Du doch überall. Dazu gibt es Tabellen- und Spaltenkommentare, die in der DDL eingefügt werden können (je nach Datenbank ist die Syntax unterschiedlich) und zum anderen natürlich eine Dokumentation des Modells in Prosa bzw. über Constraints (die Benutzer_id wird vermutlich einen FK-Constraint auf die Benutzertabelle haben). Dann weißt Du auch noch in einer Woche, dass dieses Feld die Benutzertabelle referenziert. Wenn Du aber nicht mehr sicher bist, warum das nötig war solltest Du dir die Anforderung nochmal durchlesen Dim

Die Adresse kommt in eine eigene Entität, die Personendaten ebenfalls. Weiter würde ich das nicht mehr trennen, denn ansonsten wäre es viel zu langsam hier die Daten wieder zusammenzusuchen. Das was sie macht. Wenn z.B. ein Artikel und eine Rechnung eine n:m Beziehung aufweisen, dann ist die Verknüpfungstabelle eben die Bestellposition. Die Namen sind egal, die Anzahl der Tabellen auch. Wenn Du 1000 brauchst, dann brauchst Du eben 1000. Wenn Du aber eine Beziehung mit 3 Tabellen beschreiben kannst, es ohne Not aber mit 7 machst, dann wird das Deine Performance deutlich beeinflussen sobald Last auf die Maschine kommt und die Tabellen mit Daten befüllt werden. Dim

Hi, also für die DB allgemein, dieses hier. Für PL/SQL gibts die Bücher von Steven Feuerstein Ansonsten den Concepts Guide und die PL/SQL Doku Mit dem Concepts Guid würde ich anfangen - zumindest bis erst genanntes Buch eingetroffen ist. Dim

Redest Du jetzt von Objekten oder von Entitäten (Du bist hier im Datenbankforum)? Aus Sicht einer Vererbung ist eine HiFi Anlage keine Spezialisierung einer Wohnung, gleiches gilt für die anderen Objekte. Dim

Also ich kenne Properties noch aus der C++Builder Zeit (in Delphi/Kylix war es genauso). Dort waren properties spezielle getter/setter Methoden, die die Eigenschaft besaßen, dass diese im Properties Editor der Entwicklungsumgebung auftauchten. Also z.B. hatte ein Butten die Properties Text, Color etc. die per Mausklick geändert werden konnte und sich dann auch sofort im Design wiederspiegelten. Evtl. ist das bei vb.net ähnlich. Dim