mme

Aus meiner Sicht ist das eine fehlinterpretation der 3.NF. Jede Spalte soll nur vom Primärschlüssel abhängen und nicht von einer anderen Spalte. Wenn ich den Vornamen betrachte hat dieser keine Abhängigkeit vom Nachnamen und andersherum. Wo also ist das Problem? Sonst müsste man ja auch noch das Geburtsdatum auslagern weil theoretisch könnten ja zwei Perosnen am gleichen Tag geburtstag haben. Auch das Argument die Person ist nicht eindeutig über Vorname oder Nachname identizierbar kann ich nur sagen darum geht es bei der Normalform nicht und wenn dem doch so währe, ist die Person auch sowieso nicht eindeutig über Vor- und Nachname identifiezeirbar. Dafür bräuchte man noch geburtsdatum und geburtsort...

Man kann von der alten Maschine zu der neuen einen Databaselink anlegen und dann die inhalte der Tabellen mit insert into as select rüber ziehen. Das kann man mit Scripten relativ einfach automatisieren (auch das er die richtige Reihenfolge nimmt wegen der Foreign keys). Ab 10G steht datapump zur Vefügung, das kann man entweder genauso wie exp/imp nutzen oder man läßt datapump das direkt über einen Databaselink machen.

Wenn die Datenbank sich schon länger bewährt hat, so wurde die vielleicht schon unter einer älteren Datenbankversion entwickelt und war damals vielleicht perfekt und nun mit der neuen Version arbeitet der Optimizer etwas anders und es sollte doch mal überprüft werden?? Ich verstehe nicht das sich hier einige nicht vorstellen können das Clustering bei oltp DBs nicht funktioniert? oder bezieht sich das nur auf eine Spiegelung. Oracle macht das doch nun schon ein paar Jahre..., wo ist das Problem? Bei Oracle ist die Performancesteigerung bei einem zwei Knoten Cluster zwischen 0,9 und 1,6 fachen von einem Server. Der Faktor 0,9 tritt z.B. dann ein, wenn die Datenbank nicht ganz optimal designt ist...

Hallo, das kann man so machen je nachdem was man erreichen will, aber ich habe zum Beispiel den Unterschied zwischen einer Warengruppe und einer Kategorie noch nicht begriffen. Warum hast du nicht einfach nur kategorien. Diese haben unter Kategorien und diese wieder haben auch unterkategorien, das kannst du beliebig häuft schachteln (durch das Parent). Und an die unterste ebene (oder auch an eine andere Ebene) hängst du dann die Artikel. Verknüpfungen in Access mit der gleichen Tabelle gehen genauso wie anderen DBMS auch... In einer Abfrage musst du die Tabelle einfach 2x hinzufügen (wenn du es machst wie oben ggf. 3 bzw. x mal) und dann miteinander Verknüpfen. Die erste Tabelle heißt dann kategorie und die zweite nennt access automatisch kategier1 usw. Ausserdem haben deine Warengruppen noch keinen Namen und du hast keine direkte zuordnung von warengruppen zu kategorien. D.h. du kannst nicht (oder nur mit erheblichen Aufwand) sagen welche Kategorie zu welcher Gruppe gehört. Was also nicht geht ist das der Anwender eine Warengruppe wählt. Danach bekommt er alle oberkategorien wo er eine auswählt und sieht dann alle unterkategorien innerhalb dieser oberkategorie. Hier wählt er auch eine aus und sieht dann alle Artikel dieser Kategorie... Aber wie gesagt es hängt davon ab ob du überhaupt sowas anbieten willst...

du hast einen zeilen trigger das definiert man über "for each row" wenn du das weglässt hast du automatisch einen statementtrigger... wegen der anderen sachen gucke ich nochmal...

du willst doch einen Wert setzen den du aus einer Bindevariable holst... Was du machst ist folgendes, du sagst der DB sie soll in im Schema hacos in der tabelle t_zeile den Inhalt der Spalte wert hohlen. Das ist keine Bindvariable sondern eine Spalte. Den Inhalt dieser Spalte kann er aber nicht zuweisen, weil er nicht weiß welche row du aus dieser Tabelle haben willst. Er merkt nicht das du meinst das er die Zeile nehmen soll wo er ja sowieso gerade ändert. Lösung: Bei jedem Update werden die alten werte in die Bindvariablen old.spaltenname und die neuen Werte in die Bindvariable new.spaltenname geschrieben. Also holst du dir das einfach aus dieser Bindvariable.... UPDATE hacos.t_zeile_memo set pos = :new.wert; Achtung das geht natürlich nur bei rowtriggern nicht bei statementtriggern, da bei statementtriggern mehrere Zeilen geändert werden könnten und er dann nicht weiß denn Wert welcher Zeile er nehmen soll. Grüße mme

ich habe so das ungute Gefühl, das du obwohl du wohl kurz vor deiner Abschlußprüfung stehst von Datenbankmodellen überhaupt keine ahnung hast? Ausserdem weißt du selber noch nicht mal welche Anforderungen an diese DB gestellt werden, wie sollen wir dir dann wirklich helfen? Wie bmg4ever schon schrieb kann man darüber diskutieren ob eine Festplatte in mehreren Warengruppen sein soll, aber das ist von deinen vorgaben abhängig. Nur hast du uns so gut wie keine vorgaben gegeben. Beschreibe doch erstmal ausführlich (verbal) was wie möglich sein muss und baue darauf das modell auf. Einen Artikel kann man übrigens durch eine Beziehungstabelle in mehreren Kategorien unterbringen, also eine n:m beziehung

Wir haben das Thema bei uns auch mal durchdiskutiert haben aber entgültig aufgegeben, als wir festgestellt haben, das es in Deutschland auch Orte gibt die ihre Straßen einfach durchnummeriert haben (so aller New York). Und nach unseren berechnungen fallen von unseren 500.000 Adresskundendaten ca. 10.000 durch jedes sinnvolle Schema und müssten händisch migriert werden...

Du willst damit sagen das du kein einfluss aufs Datenmodell hast(?), weil die tatsache, das die Tabellen vom CRM angelegt wurden, sagt ja nichts über die Qualität der Software bzw. des Datenmodells aus. Und das xampp sich automatisch installieren lässt ist auch klar, aber bedeutet das das es dann so optimal läuft nur weil es automatisch geht? Wenn du sowieso keine einfluss auf die software und die Architektur nehmen kannst dann bleibt dir nichts anderes übrig als eine dickere Kiste da hinzustellen. Das ist aber mehr so die Holzhammermethode. In manchen Fällen sind drei ältere Einzelrechner schneller und kostengünstiger als ein großer... Naja, das genauer zu analysieren ist vielleicht für das Zielsystem nicht lohnend...

Das kann soviele Ursachen haben... Von der Datenbank her gesehen kann es sein, das das Datenmodell einfach schlecht ist und dadurch die Abfragen lange brauchen. Ist überall da wo ein Index sein sollte auch einer drauf und und und... Bei solchen Problemen macht bessere Hardware nicht soviel aus... Das es ungeeignet ist würde ich nicht sagen, aber ich würde mir bei dieser größenordnung (anzahl benutzer usw. werden es tendenziell mehr user(?) ) schon überlegen, ob ich Datenbank, Webserver und evt. einen Fileserver alles auf eine Hardware tue. Es handelt sich einfach um verschiedene Anforderungen an diese Systeme, sodas bei uns sowas grundsätzlich auf unterschiedliche Maschinen kommt, damit jedes für sich für seine Aufgabe optimiert werden kann (zugegebener weise handelt es sich bei uns um andere Userzahlen).

SELECT COUNT(username) AS count,rank_id,rank_title FROM usertabelle LEFT JOIN rangtabelle ON usertabelle.user_rank = rangtabelle.rank_id GROUP BY rank_id, rank_title HAVING rank_id IS NOT NULL So kannst du abfragen wieviel User in einem Rank sind. In einem anderen Select kannst du dann abfragen welcher User in welchem Rank ist. Aber ich würde das nicht zusammenwerfen, da du sonst wie du schon sagtest vieles doppelt hast. Wenn du es trotzdem machen willst funktioniert unter Oracle sowas hier, ob allerdings unter mysql ein Select im Select so geht weiß ich nicht...: SELECT username, rank_id,rank_title, (select count(a.user_rank) from usertabelle a where a.user_rank = rangtabelle.rank_id) as count FROM usertabelle LEFT JOIN rangtabelle ON usertabelle.user_rank = rangtabelle.rank_id where rank_id IS NOT NULL

Bei der Abfrage würde ich anstatt "SELECT * from wg_kunden GROUP BY Vorname, Nachname, Firma" folgendes verwenden: "SELECT Vorname, Nachname, Firma from wg_kunden GROUP BY Vorname, Nachname, Firma" Dein Select ist doch meiner Meinung logisch schon nicht ganz korrekt... Du willst nach den drei Kriterien gruppieren. Das heißt wenn du drei Datensätze "Heinz", "Müller", "BMW" hast und bei jedem der drei Sätze steht aber eine andere Hausnummer. Es sollen nun die drei Sätze zusammengefasst werden zu einem Satz, aber trotzdem soll er alle drei Hausnummern anzeigen? Denn ob er die Hausnummer gruppieren addieren usw. soll hast du nichts gesagt! Warscheinlich addiert er dann die drei Hausnummer standardmäßig und der Standard ist wohl abhängig von deinem DBMS (Welches?). Viele DBMS lassen deswegen so eine Abfrage gar nicht zu. Vielleicht gibt er dir die Anzahl, oder die Quersumme der Hausnummer aus, du gibst ihm ja nichts vor für die anderen Spalten, also lass sie weg. Anstatt * nur die Columns. Wenn du nichts summiert, oder irgendeinen Max/minwert pro Gruppierung haben willst kannst du auch distinct nehmen. "SELECT distinct Vorname, Nachname, Firma from wg_kunden"

Ich möchte aber noch mal auf das Vorurteil Oracle und zu teuer eingehen... Für uns war Oracle ein gutes stück günstiger als der MS-SQLServer. Man muss nur richtig vergleichen. Man kann eine Desktopvariante MS-SQL nicht mit der Enterprise-Oracle-Version vergleichen, sondern wenn mit der Personaledition die gerade mal nach Liste 317€ (pro User) kostet. Auch die Standard-Edition finde ich mit rund 3000 € (pro Prozessor) nicht teuer. Die meisten kippen nur um wenn sie die Enterprise sehen mit > 30.000€ pro Processor. Aber MS hat auch eine Version die mehr als 25.000€ kostet.... Ach von wegen 317€ Oracle-Personaledition - weiß einer was eine Access-Lizenz kostet?

wie greift den das FE auf das Oracle-BE zu? Per ODBC und verknüpften tabellen? Wenn ja, was steht denn dann in Access in der Verknüpften Tabelle drin?

völlig falsch würde ich nicht sagen, aber vielleicht sollten wir erstnochmal versuchen herauszubekommen wo das Problem entsteht.... Frag mal mit Sqlplus ab was in der Tabelle in Oracle drinsteht. Nur um zu wissen ob das Problem bei der Datenübernahme von Access entstanden ist, oder bei der Ausgabe.

meiner Meinung zwei Möglichkeiten. Wenn die in der Applikation statements absetzten kannst, könntest du z.B direkt nach dem Connect folgendes einbauen: alter session set nls_language = GERMAN; alter session set nls_territory = GERMANY; Wenn nicht (oder auch sonst) kannst du dies auch grundsätzlich im Parameterfile der Datenbank umstellen. D.h. du musst diese einträge in das Parameterfile machen. Wie du das machst hängt davon ab ob du ein spfile hast oder ein pfile. Danach Datenbank durchstarten. nls_language = GERMAN nls_territory = GERMANY Welche Version hast du? Ich habe irgendwas im hinterkopf das man dies in früheren Versionen noch nicht konnte... Aber versuch es einfach, er wird dir dann ein Fehlermeldung geben wenns nicht geht.

einstellen kannst du das an vielen stellen Welches betriebsystem auf dem Server welches auf dem client...? am windowsclient z.B. in der regestry: hkey_local_machine\software\oracle\.... dort und in den unterordnern nach nls_lang schauen Hier z.B. ein deutsches Datum- und zahlenformat und entsprechender Zeichensatz: GERMAN_GERMANY.WE8MSWIN1252 alternativ z.B.: AMERICAN_AMERICA.WE8IDO8859P1 Dies beeinflusst am Client natürlich nur aus/eingabe. Nun ist die Frage wo das Problem entsteht. Am client, oder beim Import auf dem Server... Den gleichen Regestryeintrag kannst du auch auf dem Server machen (wenn windows) und dann schau die mal die DB-Parameter an. In SQLPLUS eingeben: show parameter nls Dann schauen wir mal weiter...

Meiner Meinung hast du keinen Denkfehler... das Feld darf einfach kein Autowert sein, sondern muss vom Anwender oder automatisch im Formular gefüllt werden. Wenn du es automatisch im Formular machen willst, kommst du an vba wohl nicht vorbei.

Nur lösbar durch tiff erstellung o.ä.

Klar kann man so machen, aber du hast dann keine Möglichkeit detalierte Auswertungen zu machen (z.B. wieviel Umsatz mit Klopapier hatten wir mit dem einen Kunden. Es geht dann nur der Gesamtumsatz des Kunden). Aber wenn du das nicht brauchst, super. Ja stimmt, aber dann würde ich den Verweis auf die Bestellung nicht bei jedem Artikel aufhängen sondern einmal für die ganze Rechnung. Da kann man aber wieder sagen was ist wenn er mehrere Bestellungen mit einer Rechnung geliefert bekommt.... (Bei uns würden dann auch zwei Rechnungen geschrieben) Also abhängig von deinen Geschäftsprozessen. Ich bezog das nicht auf Privater und Geschäftlicher Kunde, hier macht mein vorschlag nur Sinn, wenn du tatsächlich Kunden hast, wo Kunde und Lieferant tatsächlich identisch sind. Hast du sowas nicht hast du auch keine Vorteile... Ach und das mit dem zusammengesetzen Primärschlüssel gilt auch für die Tabelle Artdetail...

von wegen 10GR2. Die ist ja noch nicht mal auf der hälfte der Systeme verfügbar und teilweise noch im deleveloper Relaise... Ich glaube da kann man noch nicht wirklich eine Aussage machen. RAC: Ist empfehlenswert. Allerdings ist deine Frage nicht zu beantworten indem man Fragt was schöner ist, sondern die Frage ist was ist kostengünstiger. Wenn du nur eine StandardEdition hast, ist RAC ja kostenlos bei 10G. (Aber ich glaube auf 2 CPU begrenzt?). Wenn du sowieso eine EnterpriseEdition brauchst (wie bei uns) ist es ein teurer Spaß. (Rund 16.000€ Netto pro beteiligter Prozessor zusätzlich zu den normalen Lizenzkosten die ja bei 32.000€ pro Prozessor liegen. Allerdings Listenpreis ). Aus meiner Sicht ist es zu komplex um sich da kurz mal reinzufuchsen. Da musst du dir schon einige Zeit nehmen wobei wenn es erstmal läuft ist es relativ pflegearm, wenn man weiß was man tut. Aber ich denke wenn ein "dicker Hobel" noch reicht für die DB und das wissen ums RAC nicht eh gebraucht wird, ist es ohne RAC besser (günstiger, effizienter)... grüße mme

Es gibt noch eine Zwischenlösung. Du musst nicht für jede Rechnung die Artikeldaten speichern, sondern du Speicherst beim Artikel von wan bis wann diese "Version" des Artikels gültig ist. Dann schaust du anhand des Rechnungsdatums was genommen werden soll. Vielleicht war mein Biespiel nicht oben nicht so gut. Nehmen wir lieber den Preis anstatt die Beschreibung. Zum 1.09.2005 erhöht sich der Preis um 5€. Dafür generierst du dann einen komplett neuen Artikel? Oder jemand hat die alte Rechnung verloren usw. und will nun ne neue und bekommt den höheren Preis, welcher Kunde akzeptiert das denn? (Oder du willst gucken was der Kunde vor einem Jahr für den gleichen Artikel für einen Preis bezahlt hat, nur leider steht auf der Rechnung bei Aufruf nur der aktuelle Preis...) Mit der Adresse kannst du auch einen gültigkeitszeitraum angeben. Es wird die Adresse des Rechnungsdatums genommen. Sollte das Rechnungsdatum in der Vergangenheit liegen, sollte das Programm gucken ob es etwas neues gibt und dich daraufhinweisen. Dann generierst du die Rechnungeinfach neu mit dem aktuellen Datum und schon hast du die aktuelle Adresse. Besser ist das meiner Meinung schon, die Frage ist nur welche Anforderungen bestehen und wie die Geschäftsprozesse sind, sodas dies entsprechend genutzt wird...

Ach und noch was... Ich würde mir überlegen, ob ich nicht alle Personendaten/Firmendaten in eine Tabelle mache. Da ein Kunde manchmal auch Lieferant sein kann. Dann würde ich eine laufende Nummer als ID nehmen und irgendwo ein (oder zwei) Kennzeichen setzten ob dieser Datensatz kunde, Lieferant oder beides ist.

Ja, der Einwand von Schwarzl ist aus meiner Sicht unbegründet... Aber z.B. an dieser Stelle solltest du dir Gedanken über die Historisierung machen (abhängig von deinen Anforderungen). Denn die Artikelbezeichnung steht ja warscheinlich auf der Rechnung. Was ist wenn du eine Rechnung erstellst und dann wird die Artikelbezeichnung leicht geändert (z.B. von "Schrauben" auf "kleine Schrauben") dann ist die Beschreibung auf einem Rechnungsnachdruck auch anders. Oder wird immer eine neue Artikelnummer vergeben wenn eine Änderung an den Artikeln gemacht wird? Gleiches gilt natürlich an anderen Stellen auch. (Ein Kundenadresse ändert sich und du willst wissen ob die letzte Rechnung noch an die alte oder schon an die neue Adresse gegangen ist...) Ausserdem fehlt eine Beziehung zwischen Bestellung und Kunde. Der Verweis von Rechnungdetail zu Bestellung ist ungenau, da du im Detailsatz auf die Gesamte Bestellung (die ja auch mehrere Positionen hat) verweist. Wenn, würde ich noch das Feld B_Position in Rechnungsdetails aufnehmen und mit Bestellungedetail verknüpfen. Und ich würde bei Bestellungdetail und auch bei Rechnungdetail die Felder Position nicht als Primärschlüssel nehmen, da jede Rechnung eigentlich mit der Position 1 anfängt und du dann aber eine fortlaufende Nummer brauchst. Also würde ich Position immer bei 1 anfangen lassen und den Primärschlüssel als zusammengesetzten Primärschlüssel aus Position und R-Nr bzw. B-Nr machen. Arbeite davon mal das ein was du glaubst anhand deiner Anforderungen zu brauchen und Poste das dann nochmal... Grüße mme

Ich habe auch schon mal eine 10G aufgesetzt und hatte wenige Probleme. Allerdings ist das ja sehr betriebssystem abhängig. Von wegen 10G R1: Ich denke man sollte Produktiv kein R1 einsetzen sondern in jedem Fall auf R2 warten (es sei den man ist referenzkunde von Oracle und hatt die sowieso ständig im Haus sitzen). Wenn ich mir überlege wie es mit 9i R1 war (und die System werden komplexer) so sollte man daraus gelernt haben sowas nicht einzusetzen.