dbwizard

- Mengengerüst : Wieviele Kunden sollen verwaltet werden ? Einer ? 10 ? 100000000000 ? Wie lange sollen die Daten aufbewahrt werden ? Historisierung ? Logging ? Wie schnell wachsen die Daten ? - Dokumente : Soll Volltextrecherche in allen Dokumente angeboten werden ? --> Das kann zu *grossen* Indizies führen. Grösse der Dokumente ? Durchschnittlich Anzahl pro Kunde ? etc etc - Allgemeiner Platzbedarf : Archivlogs / Redo Logs, evtl Platz für Export, Backup ? Wie du siehts, musst du dir dazu noch einige Überlegeungen machen Gruss

- RAID 5, wenn schon - Betreff der Grösse : Dazu fehlen praktisch alle relevanten Informationen : -> Mengengerüst ? Datentypen (Werden z..b Binaries wie gescannte Dokumente etc mitgespeichert ) ? Schätzungen zu Wachstum (Anzahl neuer Daten pro Zeiteinheit) ? Gruss

Hallo, Die Doku ist immer ein guter Start... MERGE Gruss

Ja, hängt aber von deinem DB-System ab.... Bei Oracle wäre es SELECT COLUMN_NAME FROM all_tab_Columns WHERE OWNER = 'mySchema' AND TABLE_NAME = 'myTable' Gruss

Hmm..Geht ein SLA nicht mehr Richtung Betrieb ? D.h. Servicezeiten, Verfügbarkeit, Festlegen der zu liefernden Qualität und Quantität etc ? Gruss

Ja bitte, kein Problem (Ich glaube aber zu wissen, das MSSQL dies nicht so unterstützt, aber eben.... CREATE SEQUENCE mySequence INCREMENT BY 1 START WITH 1 MINVALUE 1 MAXVALUE 999999999999999999999999999 NOCYCLE NOORDER CACHE 20 / INSERT in myTable (ID,Attribute1,Attribute2,xxxxx) VALUES (mySequence.Nextval,'Value1','Value2',xxxx) / COMMIT; Gruss

- Jein...In Oracle schon :-) . Aber das hilft dir eher nicht... Gruss

ja, die Befürchtung habe ich auch. Wie wäre es : - Mit deinem Datenmodel ? - Deiner Abfrage, welche das Problem beinhaltet? Gruss

- Ich weiss es nicht, diese Frage kannst nur du beantworten ? Sind die ID's als PK definiert ? Dann wirst du : - Entweder die ID's mitnehmen müssen - oder auf der Zieltabelle neu generieren lassen Ist die ID in der Zieltabelle der FK auf die Sourcetabelle, dann musst du sie natürlich mitnehmen. (Im übrigen dachte ich, dass die Daten auf der zieltabelle schon existieren, deswegen das UPDATE-Statement.... Gruss

ja - Neues Attribut in Zieltabelle erstellen (Dies ist Oracle Syntax...aber sollte nicht allzu schwirig sein, dies anzupassen....: ALTER TABLE Zieltabelle ADD ( NeuesFeld VARCHAR2 (20) ) / - Kopieren der Werte aus der Sourcetable in die Zieltabelle UPDATE Zieltabelle SET NeuesFeld =Select AltesFeld from Sourcetable where Sourcetable.id=Zeiltable.id Gruss

- Ansonsten könntest du auch ins Auge zu fassen, die Parameter in eine Collection zu packen, ist eh eleganter um nachher das Statement aufzubauen Gruss

- Und welche Fehlermeldung kommt ? Wenn du hier Hilfe willst, musst du dein Problem schon etwas spezifischer Beschreiben.

Hallo, Noch ein paar Anmerkungen : - Was bedeutet "Wenn mehrere Elemente" gespeichert werden müssen ? Ein Tabelle enthält Daten einer berstimmten Entität, also z.b eine Person. D.h. es könne in der Personentabelle n Personen gespeichert werden. Wenn du zu diesen Personen noch Adressen speicher möchtest, kannst du : - Diese Adressen in der Tabelle Person mitspeichern, indem du die Tabelle um die entsprechenden Attribute erweiterest (Du kannst so aber nur 1 Adresse pro Person speichern, also eine 1:1 Beziehung herstellen) - Oder die Adressen in einer eigenen Tabelle ablegen, welche über einen Fremdschlüssel zur Personetabelle referenziert. Damit kannst du zu einer Person n-Adressen speichern (1:n) Beziehung. - (Lassen wir mal die n:m Bezeihung hier beiseite...) - Du "speicherst" keine Reihenfolge. Die Reihenfolge, in der die Daten ausgegeben werden, wird allein durch das ORDER BY in der Abfrage bestimmt. - Wenn du in der Wikipedia nachguckst, findest du eine ausführliche Darstellung eines RDBMS, vielleicht wäre dies mal eine Idee ? --> http://de.wikipedia.org/wiki/Relationale_Datenbank Gruss

- Tja....und was wäre denn deine Frage ?

- Hallo, Die 15er Version ist die aktuellste Version. Eine "Evaluationslizenz" findest du hier : PowerDesigner.de - Dowloads Gruss

- Stimmt so nicht. Stichwort WEBDAV--> Google - .. und die Oracle Implementation dazu (Beispiel) http://www.oracle.com/global/de/community/tipps/xdb-events/index.html Gruss

- Nein. Warum sollte dies so sein ? Jeder Monat liegt in einer eigenen Partition, es gibt nicht so etwas wie einen "unpartitionierten" Bereich (Mit einer Ausnahme). Wenn du mehrere Monate in dei Abfrage einbeziehen musst, so "schaut" die DB auf die entsprechenden Partitionen, aber dies wäre ja bei der von dir ins Auge gefasste Lösung auch so, du mpsstes da die entsprechenden tabellen per Union zusammenfassen. Die Gesamtanzahl der Datensätze bleicvht ja dieselbe Gruss

- Nein. Dies ist ja der Vorteil dieser Lösung. Wenn du die "normale" Tabelle selektieren kannst, so geht dies auch ohne einer Änderung mit einer partitionierten Tabelle. Aus Sicht Applikation verhält sich eine part. Tabelle gleich wie ein unpartitionierte Tabelle. Der Oracle Optimizer enscheidet anhand der Where Clause (Welche natürlich den Partitionig Key, hier z.b. das Datum enthalten muss), welche Partition der Tabelle gefragt ist und liest anschliessend nur aus dieser. Der Rest der Daten wird nicht einbezogen und damit hast du denselben Effekt wie deine monatlichen Tabellen, aber ohne den ganzen Overhead. Gruss

- Ja, dass verstehe ich schon, nur ist dieses Problem nicht mit der Implemention Filesystem- Datenbank lösbar. Für solch ein Szenario sind aber Technologien wie Flashback (Oracle) ideal, um solche "Benutzerfehler" wieder zu korrigieren. Oder die Applikation sorgt für eine korrekte Speicherung (Warnhinweis bei Überschreiben, "automatische" Versionierung ...) Gruss

- Eben deshalb würde ich die Tabelle pro Monat Range-Partitionieren. Wenn du den entsprechenden Monat abfragst, wird nur die betreffende Partition abgefrgt. Dies ist transparent gegenüber der Appliaktion, d.h. du musst dir Appliaktion nicht abändern. Die Lösung, für jeden Monat eine separate Tabelle zu erstellen , ist - aufwändig - Kostet unnötig Ressourcen - Kompliziert das Abfragen (was machst du, wenn du einmal mehrere Monate /Ein Jahr abfragen willst ?) - Bringt mehr Verwaltungsaufwand Für das grundsätzliche Konzept : Partitioned Tables and Indexes - Da würde ich mal meine Querys anschauen, "ein paar" Millionen Row's sind "nicht viel" - na ja, wenn du es trotzdem auf "die harte" Tour machen willst :-) : Du musst für dein Problem Dynamic SQL verwenden : http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/dynamic.htm#LNPLS011 Gruss

- Darf ich Fragen, warum du für jeden Monat eine neue Tabelle erstellen willst ? Dies führt zu einigen Komplikationen bei den nachfolgenden Abfragen und verkompliziert die Sache nur. In solch eine Fall würde sich eine Range-Partitionierung (pro Monat) "Einer" Tabelle anbieten, welche die kompletten Daten enthält. Gruss

- ja. (Ausser dass Root-Element, welches keinen Parent hat). MIt einem Hierarchischen Datenmodel kannst du prinzipiel nur 1:1 oder 1:n Beziehungen abbilden - Wenn du sie so sortierst abfragst, ja. Prinzipiell sind Daten in der Datenbank "immer" ungeordnet, nur die ORDER BY ergibt eine konsistente Sortierung [QUTOE] 3. Irgendwie kann ich mir unter einem Schema gerade nix vorstellen (kommt mir aber iwie bekannt vor) .... :confused:

- Und was hilft dabei die Implementation in ein Filesystem oder eine Datenbank, wenn der Benutzer seine Use-Case falsch abhandelt ? Soclhe Sachen müssen über die Applikation geregelt werden, welche den Benutzer z.b. darauf hinweist, dass er eine bestehende Version überschreibt oder nicht Gruss

Hallo, Da kann man natürlich verschiedener Meinung sein. Welche Vorteile das Filesystem bei den von dir beschriebebn Cases gegenüber der Datenbank bietet, ist mir nicht ganz klar : -Das macht jede Datenbank auch (Ich gehe davon aus, dass in einer produktiven Umgebung auch deine Datenbank gesichert wird ?) - Benutzt du Oracle, hast du z.b. auch die Möglichkeit, Flashback zu benutzten--> Stichwort Versionskontrolle und Historisierung - Im Filesystem fehlt dir aber einige Dinge, welche in der Datenbank "mitgeliefert" werden : > Transaktionskontrolle > Skalierung > Integration in dein restliches Datenmodel (Dokument stehen nicht alleine, es existieren Metadaten, Benutzerinformationnen, Logging etcetc... Eine interssante Diskussion bei AskTom findest du hier : http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1011065100346196442 Gruss

- Ja, wobei Oracle ab Reease 9R2 den Spaltentyp XMLTYPE kennt, so dass XML direkt gespeichert werden können (Technisnch in einenm CLOB) Gruss