Hallo Andreas, > > Zur Struktur, die vermutlich das Wichtigste beim Erstellen einer DB > ist, habe ich noch Fragen. > > 1 > Rechtfertigung für weitere Tabellen > Du verwendest in Tabelle Work für $Year ein Datenfeld, speist jedoch > die Gattung (Form) via ID ein. > Auch gleiche Werte für Jahr kommen vor.
Das Jahr ist ja bereits eine einfache Ziffernfolge. Es wird außerdem auf jeden Fall doch häufiger geändert. Wenn Du vor allem mit den Base-Formularen etwas über ein Listfeld eingibst ist die Neueingabe immer ein Problem. Deshalb nehme ich in Tabellen einfache Ziffernfolgen direkt mit auf. Damit das im Formular einfacher ist habe ich daraus jetzt ein Kombinationsfeld gemacht. Leider gibt es in Base noch nicht die Art Kombinationsfelder, die bei Neueingabe eines Wertes diesen in eine separate Tabelle schreiben und anschließend die entsprechende ID in die Haupttabelle übertragen. Für PHP/MySQL habe ich mir so etwas konstruiert. > > Handelt es sich dabei um eine Frage des Geschmacks oder gibt es > objektive Kriterien für eine Entscheidung. Ist wohl wirklich eine Frage des Geschmacks. Ich habe in dieser Liste auch schon Meinungen gehört, z.B. für Adressdaten einfach alles in eine Tabelle zu packen. Grundlage einer Datenbank mit Beziehungsstrukturen ist aber eigentlich, Doubletten vor allem längerer Feldinhalte zu vermeiden. > Dito für Instrumentation. Die Instrumentation schien mir einer häufigeren Wiederholung zu unterliegen. Es gibt zur Zeit 31 verschiedene Instrumentationsarten mit bei 43 Work-Einträgen. Ich vermute, dass die Wiederholungen bei der Instrumentation noch größer werden. Sollte das nicht der Fall sein, so würde sich hier natürlich eher das Verfahren wie mit den Jahreszahlen anbieten. > > 2 > WorkLengthTruth und WorkPartLengthTruth > Hier gibt es eine Abhängigkeit. Zur Zeit wird diese noch nicht durch > die Struktur abgebildet. > Beispiel: > Work.LengthTruth kann den Wert WAHR enthalten, während gleichzeitig > WorkPart.LengthTruth, bei einem Werksteil des gleichen Werkes, den > Wert FALSCH einnehmen kann. > Logisch ist das verboten. Einfachste Möglichkeit wäre wohl, die LengthTruth-Eigenschaft aus WorkPart auszulesen und dann über eine Abfrage im Hauptformular anzuzeigen (ähnlich der momentanen Anzeige der fehlenden/überschüssigen Sekunden). Da muss ich noch etwas dran überlegen. Das Dumme, wenn Du die Anzeige so machst: Du kannst die LengthTruth-Eigenschaft von Work nicht mehr beeinflussen, wenn kein Unterformular existiert. > Wenn ich Andreas Saeger richtig verstanden habe, kann man allein durch > eine richtige Struktur sowas vermeiden, ohne Makros. > Aber wie gesagt: ich bin nicht sicher, ob es so gemeint war. Das ginge m.E. nur über diese Abfragemöglichkeit. > > Kleinigkeit am Rande: Wie schreibt man eigentlich in der richtigen > Syntax über "Datenfeld 'LenghtTruth' der Tabelle 'WorkPart' der > Datenbank 'SimonBarberWork', damit man sich eindeutig verständigen > kann? > Irgendwas in der Form "SimonBarberWork.WorkPart.LengthTruth"? > Also [Datenbankdatei].[Tabellenname].[Datenfeldname]? Sieh Dir dazu die Abfrage "LegthDiff" an: "Length_Work"."ID" Bezieht sich auf die Abfrage "Length_Work" und dort auf die "ID". Du müsstest also bei der Angabe des Datenbanknamens genauso verfahren. Die Untergliederung mit dem Datenbanknamen wird z.B. bei der Einbindung von äußeren Datenbanken benutzt - für MySQL habe ich hier solche Konstruktionen. > > 3 > Nummerierung der Werksteile/ Primärschlüssel > Du hattest ja schon geschrieben, dass von Primärschlüsseln abzuraten > ist, die aus einem Datentyp als INTEGER bestehen. > In den Rohdaten tragen Werksteile IDs, die sehr klar und gut lesbar > sind: 7a, 7b, etc. > In Deiner Datenbank tragen die Werksteile IDs, die keine Schluss auf > die Zugehörigkeit zu einem Werk erlauben. > Ist es in einem solchen Fall empfehlenswert die sprechende ID manuell > als zusätzliches Datenfeld einzuführen. Die Verbindung erfolgt doch sichtbar im Formular. Wenn Du die Untergliederungen der Tabelle der Unterformulars mit a,b,c usw. sortieren willst, so muss natürlich diese Sortierung noch zusätzlich in die Tabelle WorkPart eingegeben werden. > > Sozusagen IDs für Maschinen, $WorkNumber und $WorkPartNumber für > Menschen? > Das berührt auch die Frage, ob man beim Löschen eines Datensatzes die > IDs der anderen Datensätze anpassen sollte oder nicht. > Ist es bewährte Praxis die Maschinen-IDs niemals nach dem ersten > Erstellen zu ändern? Einfaches Beispiel aus unserer Schülerbücherei: Die zuständigen Kolleginnen meinten immer, an den Mediennummern erkennen zu wollen, wie viele Medien doch in der Bücherei vorhanden sind. Sie ärgerten sich, wenn ein Medium aussortiert wurde und diese Nummern frei wurden. Ich habe dann, in meiner Naivität, eine Funktion geschrieben, die automatisch bei der nächsten Neueingabe die freigewordenen Werte belegte. Nichts mehr mit AutowertIDs. Später kam dann, dass plötzlich Medien mit der gleichen ID existierten - weil die Büchereileute von Buchverlusten ausgegangen sind, das Medium gelöscht haben und die ID neu vergeben wurde. Das ist dann so, als würde ich bei irgendeiner Firma die Kundennummer eines Vorgängers erben, weil dieser ausgetragen wurde - und der bestellt dann einfach weiter unter dieser Kundennummer auf meine Rechnung. Also IDs tunlichst nicht mehr ändern. In unserer Bibliothek ist stattdessen natürlich eine Systematik üblich, damit das Buch/die Cd o.ä. gefunden werden kann. Im PC existieren aber zur Ausleihe diese Mediennummern, die den IDs entsprechen. > > > Habe mich gerade noch einmal für 45 Minuten dran gesetzt. Irgendwie hat > > die Formatierung des Datums als JJJJ nicht richtig funktioniert. Habe das > > jetzt als 4-stellige Zahl realisiert. > > OK. Vermutest Du da einen Bug in Base? Das scheint mir ein Bug zu sein. Ich habe mich nur gewundert, dass alle Felder auf 1904 standen und eine Angabe von 1998 nicht angenommen wurde. Dann habe ich das ganze Datum sichtbar gemacht. Dort standen dann irgendwelche Komplettdaten, die anscheinend aus der Jahreszahl konstruiert wurden. Hier ließ sich dann auch die Jahreszahl ändern und anschließend wieder anzeigen. Vielleicht ist das aber auch ein Übertragungsproblem von Calc nach Base. Hier wird wohl nicht die Formatierung des Base-Feldes berücksichtigt, sondern aus "1998" ein komplettes Datum gebildet. Ob die Neueingabe mit dentsprechender Jahresformatierung funktioniert habe ich nicht mehr überprüft. > > > Zur Datenbank "Inventur": Ich lege am liebsten alle Daten, die ich in der > > Datenbank brauche, auch dort ab. Maßeinheiten sind beispielsweise nicht > > Bestandteil der darunterliegenden Datenbank, sondern auch in Base nur > > durch die Benutzeroberfläche zusätzlich einstellbar. > > Verstehe ich Dich richtig, dass Du hier Formatierungen meinst? Und > Formatierungsinformationen (Formatcode wie "0,00' EUR'") werden beim > Import der Datenbank in eine andere Anwendung nicht, oder nicht > zuverlässsig übertragen? Wenn Du die Tabellen aus Base/HSQLDB z.B. nach MySQL überträgst wird die Formatierung nicht mit übertragen. Diese Formatierung ist in Base, der Benutzeroberfläche, gespeichert - nicht in der Datenbank HSQLDB. Dort gibt es nur, grob gesagt, Zahlen - Datum/Uhrzeit - String. Nur mit Zahlen kannst Du rechnen. Das merken bei uns die SchülerInnen zum ersten Mal deutlich, wenn sie in Calc eine Rechnung mit Euros machen wollen - und "€" direkt in die Zelle schreiben: "Aber sie haben doch auch in der Tabelle die Euros stehen. Warum geht das bei Ihnen?" Das ist die Benutzeroberfläche, nicht die Rechengrundlage. Ähnlich wird die Rechengrundlage ja auch für das Jahresfeld in Wirklichkeit ein komplettes Datum gewesen sein. Deshalb steht dann in der Tabelle, wenn Du "Datum" wählst, egal wie es formatiert wird, auch ein Datum drin. Und bei Euro oder Kilogramm steht eben nur eine Zahl drin. Das schmückende Beiwerk macht die Schnittstelle zum Bediener, hier eben Base. > > > Für meine Web-Datenbanken > > entnehme ich die Werte für Listfelder grundsätzlich solchen kleinen > > Tabellen > > Was spricht denn gegen eine Aufnahme der Einheit in einem Datenfeld > derselben Tabelle? Das Prinzip der Wiederholbarkeit - wie oben beschrieben Geschmacksache. Ich mache so etwas eben bei Zeichenkombinationen, nachdem ich in der Bücherei erlebt hat, auf wie viele verschiedene Arten "kartoniert" als Bezeichnung für die Buchdruckart geschrieben wurde. Und wenn sich jemand anzeigen lassen wollte, wie viele kartonierte Bücher denn in der Bibliothek waren, dann waren das mal 1500, mal 65 und ein anderes Mal nur 4. > > Also in Inventur.Name: > $ID | $Name | $Preis | $PreisEinheit > > Für $Einheit könnte als Defaultwert "EUR" eingestellt werden. > > Oder muss man "EUR" als Konstante auffassen und es ist dann bewährte > Praxis Konstanten so in die Datenbankstruktur einzubinden, wie Du es > tust? Ich habe das Beispiel länger nicht mehr angesehen. Jetzt weiß ich erst, auf was Du hinaus willst. Es existiert dort ein kleines Tabellchen mit "-" und "€". Das habe ich gebraucht, um das Listenfeld mit den entsprechenden Informationen zu beschicken. Eine Formatierung eines Listenfeldes leistet Base, soviel ich im Gedächtnis habe, nicht. Mittlerweile würde ich die entprechende Tabelle auch auflösen und direkt in der Abfrage den Zusammenhang konstruieren. Die PreisEinheit, die Du oben einfügen willst, wird in der Inventur-Datenbank durch die Formatierung in dem Formular gewährleistet. Die Tabelle selbst habe ich damals noch nicht formatiert - bis ich gemerkt habe, dass bei einer Vorformatierung der Tabelle die Formularfelder entsprechend vorformatiert gegründet wurden. Nur bei so etwas wie dem Datumsfeld bin ich eben gerade wieder darauf reingefallen, dass nicht das Angezeigte das ist, was in der Datenbank tatsächlich abgespeichert wird. Gruß Robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
