Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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 <tom@prost-net.de>
Prost


-- 
Informationen zum Abmelden: E-Mail an users+help@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.