Am Sonntag, den 23.09.2012, 20:54 +0200 schrieb Micha Kuehn: > Tom schrieb: > > Allerdings verstehe ich den Sinn der Tabelle "Monate" nicht so ganz, > > aber es wurde - glaube ich - schon erörtert, dass man einen wie auch > > immer gestalteten Zeitpunkt besser in der Vergessen-Tabelle > > unterbringt ? > > Ich will aber nicht bei jedem Eintrag einen Zeitpunkt angeben müssen. Es gibt wahrscheinlich auch in Base (mit dem ich gerade erst beginne) andere Mechanismen für die Vorbelegung bestimmter Felder - gerade beim Datum - die genau das erledigen. Gibst Du z.B. immer alle Daten für den ganzen Monat in einer session hintereinander ein, gibt's bestimmt die Möglichkeit, das Datumsfeld mit einem default für jeden Satz vorzubelegen. Da bräuchte es aber noch etwas mehr Information zum konkreten use case. Auch der Entwurf Deiner Eingabeform ist für mich nicht so ganz einfach und unterscheidet sich ja auch von dem von Robert, der schon eher meine Arbeits- und Denkweise bei der Dateneingabe unterstützen würde. > Ich möchte den zugehörigen Monat aus einer Liste auswählen. Ob mein Alles Auszuwählende in einer einspaltigen Tabelle zu hinterlegen ist natürlich die erste Idee, aber bei Datenbanken eigentlich nicht die erste Sahne. Wir haben auch schon mit Zeit-Entitäten gearbeitet, aber dadurch entstehen all-key relations, die eigentlich nur dann Sinn machen, wenn Sie häufigen Änderungen oder Löschungen unterliegen - was bei Zeitpunkten eigentlich nicht vorkommt. Selbst bei den Fächern würde ich diese Abwägung machen wollen. Du wirst zwar hier kaum in Performance Probleme laufen, aber ich würde bei größeren Projekten so eine "Übernormalisierung" vermeiden. > Ansatz dafür richtig ist oder nicht, weiß ich nicht. Grundsätzlich Beim Datenbank-Design würde ich nie von richtig oder falsch sprechen. Es gibt immer verschiedene Möglichkeiten, das Gleiche zu erreichen - je nach Anwendungsfall kann aber die eine oder andere vorteilhafter sein ;-) > sollte aber doch eine solche Verknüpfung als 1:n-Beziehung passen und Sicher dat :-) Das scheint mir aber für den vorliegenden Fall zu restriktiv zu sein, denn dann hättest Du modelliert, dass zu jedem Zeitpunkt mindestens eine Schüler-Fach-Kombination vorkommen soll - oder zu löschen wäre, wenn er nicht verwendet wird ? - ist schon zu lange her. Damit würdest Du aber später entweder leere Datensätze erzeugen oder aber auf eine fortlaufende Zeitskala verzichten, z.B. diesen August in Bayern ;-)
Weil ich das immer sehr verwirrend fand, habe ich gerne die Modellierung gewählt, die letzlich die Zeit-Entität als Attribut in die Relation gezogen hat. SERM ? Erinnere mich leider nicht mehr so genau und will auch nicht zu sehr theoretisieren ... Und wie ich sehe habt Ihr ja beide auf die Definition der foreign keys (Verbundeigenschaften ?) der Tabellen verzichtet, so dass dieser Modellierungsschritt nicht umgesetzt ist. Muss ja auch nicht - bei HomeDataBanking ;-) Ich vermute, Base nimmt dann default-mäßig m:n ? > machbar sein, oder? Es könnte ja auch irgendwas anderes sein, was ich da > zuordnen will... > > Die Jahresangaben sind egal, die kann man in der Tat vergessen. Du willst also für jedes Jahr eine neue Anwendung stricken ? Auch nicht gerade der typische Anwendungsfall für eine Datenbank ? Schöne Grüße -- Tom <t...@prost-net.de> Prost -- Informationen zum Abmelden: E-Mail an users+h...@de.libreoffice.org Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de Listenarchiv: http://listarchives.libreoffice.org/de/users/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
