Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: Wenn er aber mal 09 oder gar nur 9, ein ander Mal aber 1992 eingibt, dann kommt die DB damit nicht klar. das kann man aber über constraints (Bedingungen) lösen Hört sich gut an. Wenn wir mal von der Semantik Jahr der Fertigstellung einer Komposition [Ganzzahl, Jahreszahl nach Christus, vier Ziffern] absehen und einen einfacheren Fall hernehmen: Gesamtzahl eingesetzter Instrumente [Ganzzahl, drei Ziffern] 09 ist zu 9 gleichwertig. Eine Integritäts-Regel, die stets strikt genau 3 Ziffern verlangen würde, wäre störend. Nützlich ist dann eine Funktion, die automatisch führenden Nullen ergänzt. Wenn ich Deine Bemerkung am Schluss richtig verstehe, dann willst Du jetzt das Kind mit dem Bade ausschütten: natürlich kann eine DB problemlos mit Integer-Zahlen unterschiedlicher Länge umgehen - ein Erzwingen von führenden Nullen ist nicht nötig. Mein Beispiel bezog sich explizit auf Deine Vorgabe Jahr: die DB behandelt die Eingabe im Grunde genommen einfach als Integerzahl. Woher soll sie wissen, dass mit der Eingabe '09' oder '9' nicht das Jahr 9 n.Chr. gemeint ist, sondern 2009 - oder vielleicht doch 1909, oder was noch (ich habe dazu angemerkt, dass in Deinem Fall Jahrzahlen aus dem Mittelalter oder gar dem Altertum wenig realistisch sind, also vierstellige Zahlen 1500 oder drei- oder weniger stellige oder gar negative Zahlen)? Und hier musst Du im Entwurf ansetzen, wobei es mindestens zwei Möglichkeiten gibt: * mit einer Gültigkeitsprüfung, wie sie Guenter vorschlägt; Access sieht - im Gegensatz zu Base - eine solche Möglichkeit explizit im User-Interface für den Entwurf vor (als Angebot: take it or leave it) * durch Benutzung eines explizit als YEAR (o.ä.) deklarierten Feldtyps, wie Du mich für PHPMyAdmin in einer früheren Mail hingewiesen hast. Ich habe mit diesem Werkzeug bisher (noch?) nicht gearbeitet, vermute aber dennoch, dass dahinter eine vierziffrige Ganzzahl 1582 versteckt ist, also die von Guenter erwähnten Constraints teilweise in die Deklaration des Feldtyps integriert wurden. Alles Andere würde wenig Sinn machen Ohne sowas wird sie bei einer Selektion nach Jahren - z.B. Alle Werke, die nach der Jahrtausendwende komponiert wurden - je nach Formulierung gewisse Werke nicht finden: Setzest Du das Selektionskriterium auf 2000 (da das Jahr 2000 bekanntlich das letzte im 20. Jh. ist), dann findet er den Eintrag 09 nicht, denn 09 2000 (als Zahlenvergleich trivial). Oder aber: Du formulierst 00, und dann wird er mit Ausnahme der im Jahr 2000 (bzw. 1900, ..., wenn die Eintragungen so weit zurück reichen) eben alles finden. Fazit einmal mehr: der Entwurf (neudeutsch Design genannt) bestimmt, was Du nachher mit der DB anstellen kannst. Natürlich kannst Du im Nachhinein den Datentyp und allfällige Constraints noch ändern - doch je nach Anzahl Datensätzen steht Dir danach (oder davor, das ist teilweise Ansichtssache) noch ein hartes Stück Arbeit bevor, denn Du musst dann alle Werte anpassen - ob per Programm oder händisch ist dabei gleichgültig. Du investierst jedenfalls ein Mehrfaches der Zeit in die Korrektur, die Du für einen sauberen Entwurf benötigt hättest. Du musst dann nämlich auch noch sämtliche Beziehungen, ... prüfen, ob sich da nicht Folgefehler der Änderung einschleichen. Übrigens: die meisten DB und Tabellenkalkulationen haben mit Datumvariablen die erwähnte Restriktion: vierstellig, 1582. Die zweite Bedingung hat mit der Kalenderreform von Papst Gregor im Oktober 1582 zu tun, die erste ist wohl eine Frage des praktischen Nutzens bzw. der internen Darstellung von Datumwerten. So ist es denn wohl eher von theoretischer Bedeutung, dass Calc bereits ab dem Jahr 9958 Probleme mit der korrekten Darstellung eines Datums bekommt (ich habe mich noch nicht bemüht, die Ursache dieser Grenze zu eruieren - wahrscheinlich hängt es eben mit der internen Darstellung von Daten zusammen). Freundlich grüsst Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Ernst, hallo Andreas, mit den Jahreszahlen gibt es natürlich keine Probleme, wenn die Datenbank explizit diesen Datentyp besitzt (ist bei MySQL der Fall nicht aber bei HSQLDB). Bei MySQL könnte dann die zweistellige Angabe ausreichen. Das würde übersetzt in 1970-2069. Da es das bei HSQLDB nicht gibt ( http://hsqldb.org/doc/guide/ch09.html ) sehe ich keine Chance, so etwas im Datenbankentwurf zu erledigen. Ich wüsste nicht, wie ich ein Minimum und ein Maximum entsprechend für ein Tabellenfeld im Entwurf vordefiniere - lasse mich aber gerne eines Besseren belehren. Ich gehe davon aus, dass ich diese Sache nicht mit dem Datenbankentwurf erledigen kann sondern die Eingabe im Formular beeinflussen muss. Das bedeutet entweder eine Beschränkung im Eingabeformular ( Das geht ja bei numerischen Feldern ganz passabel - zwingt allerdings die benutzende Person bei Fehleingaben zu der Geduld, wirklich alles 4-stellig zu schreiben.) oder aber mittels eines zweistelligen Feldes und anschließender Auswertung desselben mit einem Makro und schreiben des entsprechenden vierstelligen Wertes in die Tabelle. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Am Montag, 15. Juni 2009 schrieb Andreas Borutta: snip exkurs Syntax für Instrumentierung /exkurs Du siehst hier an diesem Beispiel schon, dass ein durchdachter Entwurf das A und O ist. Solche Sache wie zB das mit den Saxophonen, die extra aufgeführt werden und nicht ins Konzept passen, dürfen bei einem Datenbankentwurf nicht passieren. snip Dennoch finde ich, dass es der Nachhaltigkeit dient, wenn die Datenfelder der Tabelle in einer sinnvollen Reihenfolge stehen und sprechende Namen tragen. Das kann, muss aber nicht so sein. Kannst Du bitte ein konkretes Beispiel nennen, wo eine nicht sinnvolle Reihenfolge und schlechte Bezeichner von Datenfeldern die Wartbarkeit der Tabelle /nicht/ verschlechtern? Der Endanwender sieht den Entwurf, die Datenbank nicht. Er sieht Formulare und Ein- und Ausgabemasken. Der Entwickler der Datenbank entscheidet wie Datenfalder angeordnet werden. Die DB-Engine macht bestimmte Vorgaben, zB weil durch sie fest liegt, wie bestimmte Datentypen verarbeitet werden. Der Resourceverbrauch spielt eine Rolle mit. Und nicht zuletzt die interne Repräsentation des DB hat entscheidenden Anteil, was aus den Tabellen wird. Die anderen haben auch das eine oder andere Argument. Letztendlich ist es egal ob du die Tabelle ORT mit der Spaltenreihenfolge PLZ, ORTSNAME oder ORTSNAME,PLZ definierst. btw: Das ist einer der spannendsten Threads in der letzten Zeit. -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Klar. Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Die Tabellen erstellst Du dann in dem anderen System, mit Base greifst Du auf die Tabellen lesend, suchend und schreiben zu, führst auch Abfragen durch. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Relationen werden in MySQL nicht von allen Tabellentypen unterstützt. Gerade der Standardtabellentyp MyISAM hat mit irgendeiner Realtionendefinition nichts am Hut. Diese Definition machst Du anschließend mit Deinem Formular und Deinen Abfragen. Für richtige Relationen musst Du z.B. InnoDB-Tabellen wählen. Wegen dieser unterschiedlichen Tabellen taugt hier eben ein Allround-Werkzeug wie Base nicht richtig, sondern es muss zur Erstellung dieser Tabellen besser auf eine spezielle MySQL-Basis zurückgegangen werden. Auch hier gehen sicher die Meinungen auseinander. Ich erstelle alle meine Datenbanken mit phpMyAdmin - und bin damit immer gut gefahren. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, *, Andreas Borutta schrieb: Guenter Wallnig schrieb: [Warnung vor dem Anpassen von MySQL mit Hilfe von Base] Also bleibt mir als Tool zum Verwalten allein PHPmyAdmin? nein, wie Du ja auch dem vorherigen posting entnehmen kannst und hier ... Doch, es ist möglich, Felder einzufügen. Nur bietet Base das nicht in seiner GUI an. ... menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. diese Kommandozeile ist nichts anderes als ein Fenster in die Edit-Ebene von beispielsweise /usr/bin/mysql (unter Linux) Klar. Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Base ist ein Frontend, das einem Hilfestellungen geben kann, eine Oberfläche zu erstellen, und Daten aus einer Datenbank - jegweder Art - zu verwenden. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen Entwerfen - nein Erstellen - ja noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Datenbankentwurf normalisieren macht man auf dem Papier Die Relationen zwischen den einzelnen Tabellen können in Base dann erstellt werden. ich wiederhole nochmal aus meinen früheren Beitrag: In der c't 09/2003, ab S. 234 steht ein guter Artikel über Datenbanken Datenschule. Mit SQL zur eigenen Datenbank von Hajo Schulz Ein Freund von mir hat die Jahresarchive. Ich habe ihn gestern schon angeschrieben. Da Du als Verfahren die Kommandozeile erwähnst, nehme ich an, dass der Quellcode eines Tabellenentwurfes nicht in Form einer Textdatei editierbar ist, oder? Weil die MySQL-DB ja eigenständig ist (Base ist ja nur die GUI), kannst Du *sehr viel* mit den Tools für MySQL machen ... So erstellst Du mit einem Dump der DB eine editierbare ASCII-Datei, die *alle* Befehle zum Erstellen der DB enthält ... auf Wunsch sogar mit Benutzern und Passwörtern. Außerdem wählbar: nur Struktur oder Struktur mit Daten ... Dieser Dump ist eine gute Backup-Möglichkeit. Er kann auch zum Erstellen der DB auf einem anderen Rechner dienen. Habe mal nachgelesen, was Dump meint. Wohl vor allem Kopie. Aber wenn ich Dich richtig verstehe, kann man auch direkt darin editieren, ähnlich wie in einer Konfigurations-Datei. Wenn man dann die vorherige Datei durch den editierten Dump ersetzt, enthält die Datenbank alle Änderungen. Es wird nicht eine Datei ersetzt. Du solltest dich mit der Struktur und den Informationen eines Datenbank-Dumpes auseinandersetzen. Wie riskant und wie sinnvoll das ist, sei mal dahingestellt. Mich interessierte nur, ob es prinzipiell möglich ist. Grundsätzlich ja, aber IMO nur für kleine, sehr gezielte Änderungen sinnvoll Gruß Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Andreas Borutta schrieb: ... Habe mal nachgelesen, was Dump meint. Wohl vor allem Kopie. Aber wenn ich Dich richtig verstehe, kann man auch direkt darin editieren, ähnlich wie in einer Konfigurations-Datei. Wenn man dann die vorherige Datei durch den editierten Dump ersetzt, enthält die Datenbank alle Änderungen. Wie riskant und wie sinnvoll das ist, sei mal dahingestellt. Mich interessierte nur, ob es prinzipiell möglich ist. Andreas Ja - siehe dazu die vorherigen Antworten... Aber wenn es dich im Detail interessiert (was es sollte) dann liest du hier: http://dev.mysql.com/doc/refman/5.1/de/backup-policy.html Viel Freude weiterhin. Ich verfolge diese Thread mit Spannung. Wenn ich was helfen kann - melde ich mich. mfg Volker btw: Vielleicht hilft dir auch noch das Buch: Datenbanken mit Openoffice 3 (so ähnlich müsste es heissen) von Thomas Krumbein weiter?! - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo, Robert Großkopf schrieb: Hallo Andreas, Klar. Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Die Tabellen erstellst Du dann in dem anderen System, mit Base greifst Du auf die Tabellen lesend, suchend und schreiben zu, führst auch Abfragen durch. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Relationen werden in MySQL nicht von allen Tabellentypen unterstützt. Gerade der Standardtabellentyp MyISAM hat mit irgendeiner Realtionendefinition nichts am Hut. Diese Definition machst Du anschließend mit Deinem Formular und Deinen Abfragen. so kann man es auch machen. Für richtige Relationen musst Du z.B. InnoDB-Tabellen wählen. Wegen dieser unterschiedlichen Tabellen taugt hier eben ein Allround-Werkzeug wie Base nicht richtig, sondern es muss zur Erstellung dieser Tabellen besser auf eine spezielle MySQL-Basis zurückgegangen werden. Auch hier gehen sicher die Meinungen auseinander. Ich erstelle alle meine Datenbanken mit phpMyAdmin - und bin damit immer gut gefahren. Ich habe beides schon gemacht. Für mich kam es dabei auf den Einzelfall an. So kann und muss jede/r selber rausfinden, wie man am Besten ein Problem löst. Ich denke, es lohnt sich mit einem Weg anzufangen und später auch alternativen auszuprobieren. Gruß Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Andreas Borutta schrieb: Guenter Wallnig schrieb: Also bleibt mir als Tool zum Verwalten allein PHPmyAdmin? nein, wie Du ja auch dem vorherigen posting entnehmen kannst und hier ... ... menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. diese Kommandozeile ist nichts anderes als ein Fenster in die Edit-Ebene von beispielsweise /usr/bin/mysql (unter Linux) Klar. Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Programme wie 'mysql' sind rein Text-orientiert, nichts grafisches. Auf dieser Ebene kann man ALLE Einschränkungen (Constraints) machen, wie fest vorgegebene Möglichkeiten, nicht leer, ... Base stülpt der Sache ein GUI über, daß dann mit der Maus bedient werden kann. Linux User 06/2006, S. 48: Datenbanken mit OpenOffice Zitat : Was unter Windows Microsoft Access leistet, bietet unter Linux OpenOffice Base: ein komfortables grafischen Datenbank-Interface für Tabellen, Formulare und Abfragen. --- Zitat-Ende Die richtige Datenbank finden, Linux User 12/2006, S. 90 Datensilos für den Schrebergarten http://www.linux-user.de/ Auf dem Linux-Tag 1998 gab es auch einen Vortrag Linux-Datenbanken und ihre Anwendung, von Nils Faerber. Einiges davon gilt auch noch heute. Es gibt auch noch andere GUI für MySQL: KnoDa, Knorr's Datenbank http://www.knoda.org/ Siehe auch Datenbankier, Plattformunabhängige GUI-Programmierung mit Qt, Teil 5: Datenbanken, c't 05/2006, S. 214 MySQL GUI Tools Downloads, z.B. MySQL Administrator 1.2 http://dev.mysql.com/downloads/gui-tools/5.0.html ist ein mächtiges Tool Weiterhin: c't 20/2005, S. 150: Fach-Arbeiter, Werkzeug für den effizienten Umgang mit Datenbank-Engines ThinSQL Zitat : ThinSQL is a free applet-php_MySQL or applet-servlet utility that connects to an SQL server over the Internet. It's compatible with proxy servers and network firewalls because it uses HTTP as its main method of communication. --- Zitat-Ende http://www.kgo.de/ThinSQL.html Da Du als Verfahren die Kommandozeile erwähnst, nehme ich an, dass der Quellcode eines Tabellenentwurfes nicht in Form einer Textdatei editierbar ist, oder? Weil die MySQL-DB ja eigenständig ist (Base ist ja nur die GUI), kannst Du *sehr viel* mit den Tools für MySQL machen ... So erstellst Du mit einem Dump der DB eine editierbare ASCII-Datei, die *alle* Befehle zum Erstellen der DB enthält ... auf Wunsch sogar mit Benutzern und Passwörtern. Außerdem wählbar: nur Struktur oder Struktur mit Daten ... Dieser Dump ist eine gute Backup-Möglichkeit. Er kann auch zum Erstellen der DB auf einem anderen Rechner dienen. Habe mal nachgelesen, was Dump meint. Wohl vor allem Kopie. Aber wenn ich Dich richtig verstehe, kann man auch direkt darin editieren, ähnlich wie in einer Konfigurations-Datei. Wenn man dann die vorherige Datei durch den editierten Dump ersetzt, enthält die Datenbank alle Änderungen. Wie riskant und wie sinnvoll das ist, sei mal dahingestellt. Das Ganze ist nur als Backup sinnvoll, oder wenn Du Teile mal in anderer Umgebung, beispielsweise in einer Test-DB mal ausprobieren willst. Insbesondere ist die Umstellung des Typs einer Spalte, z.B. von INT auf REAL (oder so) nicht in der DB möglich, aber durch die Folge DROP TABLE Xyz CREATE TABLE Xyz kannst Du auch so etwas machen. Solange die Namen gleich und Abfragen gleich bleiben, ist das auch kein Problem. Ansonsten ist das überhaupt nicht riskant, weil Du NICHT an der DB sondern an einer Kopie in Textform arbeitest. Erst durch einen Import (oder so) wird daraus eine Datenbank. Die Gesamte DB vom (veränderten) Backup zu laden ist zwar möglich, aber bei großen DB nicht sinnvoll. Im Großen und Ganzen sieht so ein Dump etwa so aus: DROP TABLE tabellenname; CREATE TABLE tabellenname ( spaltenname1 datentyp [einschränkung], spaltenname2 datentyp [einschränkung], ... ); Mich interessierte nur, ob es prinzipiell möglich ist. Andreas Ich hoffe, alle Klarheiten sind beseitigt? MfG Günter - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Andreas Borutta schrieb:
Zu Primärschlüsseln:
Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel
Tabelle Form) zusätzlich einen Primärschlüssel.
Jeder Datensatz enthält dort jedoch einen anderen Wert.
Dubletten kommen nicht vor.
http://borumat.de/+screenshots/sc-052.png
Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen?
Andreas
Jain :)
Dazu folgender Denkansatz (ohne das ich jetzt wüsste was in dem
Datenfeld Form gespeichert wird)
Du nimmst eine Tabelle die u.a. ein Datum enthält. Dieses läst sich ja,
wie wir wissen (danke Ernst), in eine Zahl packen.
Dafür brauchst du je nach Betriebssystem und Datenbank eine gewisse
größe an Speicherplatz. Sagen wir mal 6 Byte.
Wenn du nun diese Zahl als Primärschlüssel verwendest, mit dem du auch
Relationen herstellen willst, dann findest du eben diese Zahl auch in
den zugeordneten Felder aller anderen Tabellen. Jedes mal mit 6 Byte Platz.
Führst du aber einen (sinnvollen) Primärschlüssel auf Basis einer
Ganzzahl in der Tabelle die vielleicht nur 4 Byte belegt, dann sparst du
neben Speicher auch eine Menge Rechenzeit ein.
Das ganze wird natürlich noch extremer, wenn du anstelle eines 6 Byte
Datumsfeldes, einen 50 Byte [Var{Char}] Wert nehmen würdest.
Die Frage ist auch, ob sich eine Tabelle mit nur einem Datenfeld und
einem Primärschlüssel lohnt. Das ist stark von Design der Datenbank
abhängig. U.u. spielen da noch andere Faktoren eine Rolle - wie z.B.
Geschwindigkeit, (externe) Speicherzugriffe, etc.
cu
volker
-
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Robert Großkopf schrieb: http://www.scoolonline.de/download/Musik_Klassik.odb Zu Primärschlüsseln: Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel Tabelle Form) zusätzlich einen Primärschlüssel. Jeder Datensatz enthält dort jedoch einen anderen Wert. Dubletten kommen nicht vor. http://borumat.de/+screenshots/sc-052.png Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? Dann wäre eigentlich die ganze Tabelle überflüssig. Denn wenn Du nur die Form wie Gesang oder Orchester in der Tabelle führst ergibt sich bei der Haupttabelle zwangsläufig, dass genau dieser Begriff dort eingetragen werden muss - und eben nicht eine (speicherplatzschonende) Ziffer. Sobald Du dann die Begriffe aus irgendeinem Grund ändern würdest, würde Dir die Datenbank in etwa mitteilen, dass die Änderung aufgrund von Beziehungen zu anderen Tabellen (hier: Work) nicht möglich ist - es sei denn, Du lässt automatisch alle Begriffe in Work auch ersetzen. Eine Tabelle mit einer Spalte könnte also lediglich genau dasselbe erfüllen wie eine Liste, die auch direkt im Listenfeld geführt wird. Sie vermeidet fehlerhafte ähnliche Eingaben, lässt aber den Inhalt der Tabelle munter wachsen. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Volker,
Volker Heggemann schrieb:
Andreas Borutta schrieb:
Zu Primärschlüsseln:
Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel
Tabelle Form) zusätzlich einen Primärschlüssel.
Jeder Datensatz enthält dort jedoch einen anderen Wert.
Dubletten kommen nicht vor.
http://borumat.de/+screenshots/sc-052.png
Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen?
Andreas
Jain :)
Dazu folgender Denkansatz (ohne das ich jetzt wüsste was in dem
Datenfeld Form gespeichert wird)
...
prinzipiell würde das schon gehen, solange die Werte hier EINDEUTIG
sind. Mit anderen Worten: jeder Wert darf nur EINMAL vorkommen.
Dafür brauchst du je nach Betriebssystem und Datenbank eine gewisse
größe an Speicherplatz. Sagen wir mal 6 Byte.
Wenn du nun diese Zahl als Primärschlüssel verwendest, mit dem du auch
Relationen herstellen willst, dann findest du eben diese Zahl auch in
den zugeordneten Felder aller anderen Tabellen. Jedes mal mit 6 Byte Platz.
Führst du aber einen (sinnvollen) Primärschlüssel auf Basis einer
Ganzzahl in der Tabelle die vielleicht nur 4 Byte belegt, dann sparst du
neben Speicher auch eine Menge Rechenzeit ein.
Das ganze wird natürlich noch extremer, wenn du anstelle eines 6 Byte
Datumsfeldes, einen 50 Byte [Var{Char}] Wert nehmen würdest.
...
cu
volker
ist es nicht so, daß aus dem Primärschlüssel ein Index gebildet wird und
NUR dieser in Relationen verwendet wird? Relativ sicher bin ich mir, das
dies in PostgreSQL so ist.
Mir ist zumindest so, als wenn z.B. eine BLZ, die für die man als ZAHL
ja schon ein LONG INT braucht, sehr gut als PK verwenden kann. Ähnliches
gilt für PLZ als Zahl.
MfG
Günter
-
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Guenter Wallnig schrieb:
Hallo Volker,
Volker Heggemann schrieb:
Andreas Borutta schrieb:
Zu Primärschlüsseln:
Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel
Tabelle Form) zusätzlich einen Primärschlüssel.
Jeder Datensatz enthält dort jedoch einen anderen Wert.
Dubletten kommen nicht vor.
http://borumat.de/+screenshots/sc-052.png
Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen?
Andreas
Jain :)
Dazu folgender Denkansatz (ohne das ich jetzt wüsste was in dem
Datenfeld Form gespeichert wird)
...
prinzipiell würde das schon gehen, solange die Werte hier EINDEUTIG
sind. Mit anderen Worten: jeder Wert darf nur EINMAL vorkommen.
Dafür brauchst du je nach Betriebssystem und Datenbank eine gewisse
größe an Speicherplatz. Sagen wir mal 6 Byte.
Wenn du nun diese Zahl als Primärschlüssel verwendest, mit dem du
auch Relationen herstellen willst, dann findest du eben diese Zahl
auch in den zugeordneten Felder aller anderen Tabellen. Jedes mal mit
6 Byte Platz.
Führst du aber einen (sinnvollen) Primärschlüssel auf Basis einer
Ganzzahl in der Tabelle die vielleicht nur 4 Byte belegt, dann sparst
du neben Speicher auch eine Menge Rechenzeit ein.
Das ganze wird natürlich noch extremer, wenn du anstelle eines 6 Byte
Datumsfeldes, einen 50 Byte [Var{Char}] Wert nehmen würdest.
...
cu
volker
ist es nicht so, daß aus dem Primärschlüssel ein Index gebildet wird
und NUR dieser in Relationen verwendet wird? Relativ sicher bin ich
mir, das dies in PostgreSQL so ist.
Mir ist zumindest so, als wenn z.B. eine BLZ, die für die man als ZAHL
ja schon ein LONG INT braucht, sehr gut als PK verwenden kann.
Ähnliches gilt für PLZ als Zahl.
Ja, klar kann man das machen.
Aber dann muß man auch darauf achten, das der User dort nur Zahlen
eingibt. Was wenn einer bei BLZ eine Internationale IBAN speichern will?
Oder auf einmal vor die PLZ noch das Land schreibt?
Sprich - dann muß die Datenbankoberfläche auch eine Eingabeprüfung machen.
Und ich schrieb ja auch, das ich keine Kenntnis des Inhaltes des Feldes
Form habe. Was ich meine gelesen zu haben ist, das dieses Feld per 1:n
Relation mit weiteren Tabelle verknüpft ist.
mfg
Volker
-
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
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
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, auch wenn jetzt die Warnungen von allen möglichen Seiten kommen: ich frage mich, wozu denn dann das Base-Modul da ist, wenn die Bedenken für die Erstellung von Datenbanken so groß sind. Ich habe an meiner Schule auch die entsprechenden Bedenken von allen möglichen Leuten gehört, als wir das damalige Datenbankprogramm nicht von DOS nach Windows für 2000,- DM portieren wollten sondern ich die Erstellung einer Datenbank auf der Grundlage der vorliegenden Tabellen mit Hilfe von StarOffice 5.1 und dem damaligen Adabas übernommen habe. Es hat geklappt, die Folgeprodukte wurden besser und werden in der Praxis in mehreren Schulbibliotheken ohne Probleme angewandt - von einem Amateur erstellt, der zu seinen Studienzeiten noch nicht einmal einen Taschenrechner beutzte. 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. Ich habe die LengthTruth-Abfrage einmal konstruiert und hochgeladen. Ist aber in reinem SQL geschrieben, so dass sie nicht im Grafikmodus angesehen werden kann (Für die Experten: CASE WHEN ... THEN ... WHEN ... THEN ... ELSE ... END geht nicht mit der GUI). Die Abfrage produziert eine Meldung im Formular, die angibt, dass die Truth-Eigenschafft stimmt oder eben nicht. Wenn das Ganze wirklich ein reibungsloses Formular werden soll kommst Du vermutlich nicht an Makros vorbei. Ich weiß ja nicht, wie hoch die Ansprüche angesiedelt sind. Ich selbst würde da die PHP/MySQL/JavaScript-Variante nehmen. Nur dauert das entsprechend wesentlich länger, da einem die Benutzeroberfläche in Base doch entschieden Arbeit abnimmt. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo, Am Sonntag, 14. Juni 2009 schrieb Robert Großkopf: Hallo Andreas, auch wenn jetzt die Warnungen von allen möglichen Seiten kommen: ich frage eine dieser Seiten bin ich.. mich, wozu denn dann das Base-Modul da ist, wenn die Bedenken für die Erstellung von Datenbanken so groß sind. Ich habe an meiner Schule auch die entsprechenden Bedenken von allen möglichen Leuten gehört, als wir das damalige Datenbankprogramm nicht von DOS nach Windows für 2000,- DM portieren wollten sondern ich die Erstellung einer Datenbank auf der Grundlage der vorliegenden Tabellen mit Hilfe von StarOffice 5.1 und dem damaligen Adabas übernommen habe. Das hier ist der Knackpunkt. Du hattest einen fertigen Datenbankentwurf (aka fertige Tabellen). Diese Tabellen musstest du nur übernehmen und ein Frontend dran programmieren. Es hat geklappt, die Folgeprodukte wurden besser und werden in der Praxis in mehreren Schulbibliotheken ohne Probleme angewandt - von einem Amateur erstellt, der zu seinen Studienzeiten noch nicht einmal einen Taschenrechner beutzte. Dafür meine Anerkennung, denn das ist nicht trivial. Aber es ist kein Datenbankentwurf. Aufgrund deiner Erfahrung kannst Du vermutlich jetzt eine Datenbank entwerfen. Aber es gehören ein paar Konzepte dazu, die man verstanden haben muss, sonst kann das ganz schnell ganz schön schief gehen. Der Hinweis von Andreas Säger mit dem Bogen Papier und den Buntstiften trifft den Kern (btw ich würde mindestens DIN A2/A1 nehmen :-) ). Das Erkennen der Abhängigkeiten und der daraus resultierende Entwurf der Datenbank ist absolut essentiell. Eine Datenbank ist im wesentlichen statisch und eine nachträgliche Änderung/Ergänzung mündet normalerweise im Chaos. @ Andreas Borutta Du agierst als Dienstleister für einen Freund und solltest dich auf jeden Fall mit den Hintergründen zu Datenbanken befassen. Zumal du, laut eigenem Bekunden, planst, diese Datenbank anderen Komponisten zur Verfügung zu stellen. Das kann nur funktionieren, wenn das Konzept stimmt. Ansonsten nagelt dich dein Freund ans Kreuz. Genug der Bedenken, ich will euch nicht den Spass verderben, sondern nur darauf hinweisen, dass die Theorie nicht zu kurz kommen darf. Ansonsten wünsche ich viel Erfolg. -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
Re: [de-users] Re: Re: Datenbank: Werk eines Komponisten
Hallo Mathias, auch wenn jetzt die Warnungen von allen möglichen Seiten kommen: ich frage eine dieser Seiten bin ich.. mich, wozu denn dann das Base-Modul da ist, wenn die Bedenken für die Erstellung von Datenbanken so groß sind. Ich habe an meiner Schule auch die entsprechenden Bedenken von allen möglichen Leuten gehört, als wir das damalige Datenbankprogramm nicht von DOS nach Windows für 2000,- DM portieren wollten sondern ich die Erstellung einer Datenbank auf der Grundlage der vorliegenden Tabellen mit Hilfe von StarOffice 5.1 und dem damaligen Adabas übernommen habe. Das hier ist der Knackpunkt. Du hattest einen fertigen Datenbankentwurf (aka fertige Tabellen). Diese Tabellen musstest du nur übernehmen und ein Frontend dran programmieren. Das kannst Du nicht wissen: Deine Vermutung ist falsch. Die vorliegende Datenbank war eine, die eben nicht relational aufgebaut war. Lediglich ein Tabellenrest der ursprünglich nach dBase-Art aufgebauten Datenbank ist jetzt noch zu erkennen. Die Relationen habe ich selbst gestrickt. Natürlich habe ich mich im Laufe der Zeit sachkundig gemacht, vor allem, als es von StarOffice weg zu MySQL und PHP ging. Und dann sind es entschieden mehr Datenbanken geworden: Haushalt und Finanzen der Schule, Adressen, Beiträge usw. des Sportvereins, CMS-System für eine Homepage ... Ich möchte andere ermutigen, selbst die Sache in die Hand zu nehmen. Wenn nur immer mit professionellem Anspruch gewunken wird, wird keiner mehr das Base-Modul anrühren. Ich bin eher der Typ, der andere ermutigt, etwas zu tun. Unter anderem aus diesem Grund bin ich Lehrer geworden. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
