Hi Salvalaggio Am 16.03.10 06:51, schrieb Salvalaggio Marino: >> ... >> Das macht es dann auch viel einfacher, z.B. alle Einträge einer >> Abteilung zu listen. > > Ja, das ist schon so, der beste Weg ist sicher, wenn aus diesen > einzelnen Tabellen, Du nennst sie Stammdaten, eine Neue erzeugt wird, > die die einzelnen Primärschlüssel als verbundene Fremdschlüsse; wie man > das richtig benennt weiss ich nicht, hat.
Nein, du erzeugst nicht aus den alten Tabellen eine neu, Du referenzierst aus einer Tabelle "Dokument" auf diese drei (was erst mal sicherstellt, dass in einer "Laufnummer" z.B. keine Abteilung vorkommt, die gar nicht existiert). Diese Tabelle "Dokument" braucht auch einen Primärschlüssel - den kannst Du nach Belieben definieren, das als zusammengesetzten Schlüssel zu machen ist nur eine Möglichkeit, du könntest auch (wie oft üblich) einfach ein Feld "Dokument.ID" definieren, das einen fortlaufenden Zähler hat und so einen Inhaltsleeren (i.S.v. "keine Bedeutung tragendenden") Primärschlüssel erzeugt. Dazu würden nur die > Stammdatentabellen über Eingabeformulare zu Editieren sein. Die > Abgeleitete Tabelle selber gewährt von Aussen nur Lesezugriff und ist > jene, auf die von den Arbeits-Formularen aus zugegriffen wird. Du willst aber ja auch mal ein neues Formular erzeugen :-) > Zum anderen aber, Numerische oder String Variable.... Da habe ich schon > gewisse Vorbehalte. > Die stammen aus meiner Praxis der Programmierung. Diese liegen auf der > Ebene der Funktionalität und Rechenintensivität gekapselter Programmteile. Ja klar, C (oder fast jede andere verbreitete Sprache) ist besser beim Zahlenschubsen. Das hier ist aber eine Datenbank - der ist es erst mal völlig egal, was an Position(Index Nr soundso) aus dem file gelesen und an dene client weitergegeben wird - es sind halt "nur" ein paaar bit mehr Daten. Wie gesagt - du rechnest ja nie damit, es ist ja reiner I/O. Andererseites gewinnst du viel Sicherheit durch eine korrekte Typisierung. Und vermeidet die dauernden integer-zu-string-Konvertierungen und andere von Dir ja schon genannten Merkwürdigkeiten. Ist letztlich aber eine Frage des Programmierstils. Ich bin aber ziemlich sicher: Es würde auf das Startverhalten Deiner Anwendung keinen messbaren Einfluss haben. > > Ich weiss jetzt nicht...Ich will ja die Listen nicht mit > Dingen zu müllen, die doch niemand liest. Ist schon klar. s.o. > > Ich möchte dazu auf folgende Tatsache verweisen. Habt Ihr Euch schon mal > überlegt, woher es kommt, dass die Aufstartzeit vonn OOO so lange dauert? > Setzt das Programm mal auf einer alten Mühle auf..... >:o Hast Du das schon mal mit der 3.2 gemacht. Schnall' Dich aber vorher an :-) > > Auf der Steuerungseben, wo ich zumeist tätig bin, wäre solches Verhalten > unbrauchbar. Ah - daher kommen diese "komischen" Ansichten :-) Na ja - Office-Pakte müssen halt nicht in Echtzeit arbeiten. Das ist absolut nicht Kritik an der geleisteten Arbeit. > Aber auf diesem Sektor besteht meiner Erachtens Nachholbedarf. Wobei ich > Anmerke, dass ich da bei den anderen Produkten auch nichts besseres zu > sehen bekomme. Letztlich ist es eine Frage der Ressourcenverwendung im Projekt - sozusagen "schnellerer Start oder funktionierendes Datenbankmodul?". Ich könnte mir aber andererseits schon ein paar Leute vorstellen, die da wirklich froh über Deine Hilfe wären. -- Mit freundlichen Grüßen Uwe Altmann OpenOffice.org auf dem Mac: http://porting.openoffice.org/mac/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
