Hallo! Ich habe die User-doku zu PostgreSQL durchgelesen und will nun eine DB fuer meine Buecher erstellen. Die DB soll Serie, Titel, Author und Verlag beinhalten. Das Problem ist, dass es pro Serie zw. 1 und 50 Titel geben kann, dadurch bin ich auf 2 Loesungsmoeglich- keiten gekommen: 1: Eine Tabelle mit Serie, Titel und eine mit Serie, Author, Verlag 2: Eine Tabelle mit Serie, Titel, Verlag und Author, wobei "Titel" ein Array ist. Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde, nur steht in der Doku, dass Arrays meist auf schlechtes Datenbankdesign zurueckzufuehren sind. Da ich noch nie eine DB erstellt habe, moechte ich gerne eure Meinung zu diesem Thema wissen. (Gibt es vielleicht sogar noch eine bessere Loesung die ich uebersehen habe?) Bin fuer jeden Tip dankbar. -- mfg Martin Neuditschko
Hallo, at Fri, 31 May 2002 11:16:29 +0200 Martin Neuditschko wrote:
dadurch bin ich auf 2 Loesungsmoeglich keiten gekommen: 1: Eine Tabelle mit Serie, Titel und eine mit Serie, Author, Verlag 2: Eine Tabelle mit Serie, Titel, Verlag und Author, wobei "Titel" ein Array ist.
Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde,
Leg eine zusätzliche Tabelle für serie und Titel an. Ich würde die Tabellen folgendermassen erstellen. Tab1: authorid, author, verlag Tab2: serieid,authorid,titel,serie Jetzt packst Du in Tab2 alle Titel und Serien rein und in authorid die ID des Autors in Tab1. Gruß Michael -- Homepage http://macbyte.info/ | Registered Linux User #228306 Phone/Fax +49 7000 MACBYTE | http://counter.li.org GNU GPG-Key ID 0140F88B | ICQ #151172379 +Webdesign #Don't send HTML coded Mails# PHP Development+
On Sun, Jun 02, 2002 at 11:56:24AM +0200, Michael Raab wrote:
Hallo,
at Fri, 31 May 2002 11:16:29 +0200 Martin Neuditschko wrote:
dadurch bin ich auf 2 Loesungsmoeglich keiten gekommen: 1: Eine Tabelle mit Serie, Titel und eine mit Serie, Author, Verlag 2: Eine Tabelle mit Serie, Titel, Verlag und Author, wobei "Titel" ein Array ist.
Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde,
Leg eine zusätzliche Tabelle für serie und Titel an. Ich würde die Tabellen folgendermassen erstellen.
Tab1: authorid, author, verlag Da Buecher von einem Autor nicht immer beim selben Verlag erscheinen muss ich die Tabelle wohl noch aufteilen. Tab2: serieid,authorid,titel,serie Damit würde ich für jeden Titel auch die autorid mitspeichern, was aber IMHO nichts bringt. Da wäre die Aufteilung: TabA: autorid, verlagid, serie und TabB: serieid, titel besser.
Für was sind eigentlich die ids gut? Nur um ein paar Bytes zu sparen? Und soll ich die ids selbst erstellen oder von der Datenbank generieren lassen? -- mfg Martin Neuditschko
Hi Martin, Am Sonntag, 2. Juni 2002 17:06 schrieb Martin Neuditschko:
On Sun, Jun 02, 2002 at 11:56:24AM +0200, Michael Raab wrote:
Tab1: authorid, author, verlag
Da Buecher von einem Autor nicht immer beim selben Verlag erscheinen muss ich die Tabelle wohl noch aufteilen.
Tab2: serieid,authorid,titel,serie
Damit würde ich für jeden Titel auch die autorid mitspeichern, was aber IMHO nichts bringt. Da wäre die Aufteilung: TabA: autorid, verlagid, serie und TabB: serieid, titel besser.
Für was sind eigentlich die ids gut? Nur um ein paar Bytes zu sparen? Und soll ich die ids selbst erstellen oder von der Datenbank generieren lassen?
Damit Du zwischen den Tabellen Beziehungen herstellen kannst. Daher haben die relationalen Datenbanken ihren Namen. Du brauchst keine Sorge haben, die Datenbanken kümmern sich da schon selbst drum, aber Du mußt ihnen sagen, daß Du damit arbeiten willst. Helga -- ~~~~~~~~~~~~~~~~~~~~~~Wer macht mit?~~~~~~~~~~~~~~~~~~~~~ Das dt. Dokumentationsprojekt von OpenOffice.org sucht Mitstreiter # Projekt-Einstieg: http://lang.openoffice.org/de # Mailingliste: http://lang.openoffice.org/de/about-mailinglist.html
Moin,
* Martin Neuditschko
Bin fuer jeden Tip dankbar. Bitte jede Frage nur einmal stellen.
Thorsten -- I can conceive no system more fatal to the integrity and independence of literary man than one unser which they should be taught to look for their daily bread to the favor of ministers and nobles. - Thomas Babington Macaulay
Hallo Martin, Am Freitag, 31. Mai 2002 11:16 schrieb Martin Neuditschko:
Ich habe die User-doku zu PostgreSQL durchgelesen und will nun eine DB fuer meine Buecher erstellen. Die DB soll Serie, Titel, Author und Verlag beinhalten.
[...]
Da ich noch nie eine DB erstellt habe, moechte ich gerne eure Meinung zu diesem Thema wissen. (Gibt es vielleicht sogar noch eine bessere Loesung die ich uebersehen habe?)
Bin fuer jeden Tip dankbar.
Hmmm... auch auf die Gefahr hin, daß mir jetzt so mancher ins Gesicht springen will, wie wäre es mit einem Gang in die nächste größe Buchhandlung und Du schaust Dir mal an, was es zum Thema Datenbank-Design/SQL gibt? Zu Postgres gibt es ein deutsches Buch von Bruce Momjian: PostgreSQL - Einführung und Konzepte. Datenbank-Grundlagen kommen allerdings etwas zu kurz. Hier kann ich eigentlich nur einen Abstecher in die MySQL-Ecke empfehlen, hier existiert ziemlich viel Thema, auch Grundlagen. Zuletzt: Nur-SQL-Bücher, die sich zumeist mit den Grundlagen beschäftigen und auch erklären, wie man eine Datenbank designt. Ein wichtiges Stichwort ist 'Normalisierung', 'Primärschlüssel', 'Fremdschlüssel'. Über google findest Du da bestimmt einiges. Die SQL-Befehle erlauben Dir, Deine Datenbank anzulegen und darin dann die Tabellen einzurichten (create database, create table). Abfragen kannst Du das alles mit select ... from. Für diese Operationen steht Dir eine Art Kommandozeile zur Verfügung, der bist Du vermutlich schon begegnet. Ein bißchen erleichtern könnte Dir phpmyadmin die Sache, das gibt es meines Wissens auch in einer Postgres-Variante, allerdings nicht so ausgefeilt. Wenn Du ein bißchen mit UnixODBC rumfummeln willst, Posgres läßt sich auch von OOo aus ansprechen. Dann kannst Du sehr bequem Deine Tabellen reinkloppen. Jetzt doch noch eine Bemerkung hierzu:
1: Eine Tabelle mit Serie, Titel und eine mit Serie, Author, Verlag 2: Eine Tabelle mit Serie, Titel, Verlag und Author, wobei "Titel" ein Array ist.
Du hast in Deinen Tabellen viel zu viele redundante Informationen. Man versucht grundsätzlich, die einzelnen Rubriken nur einmal vorkommen zu lassen (läßt sich nicht immer vermeiden, ist auch nicht immer sinnvoll).
Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde, nur steht in der Doku, dass Arrays meist auf schlechtes Datenbankdesign zurueckzufuehren sind.
Was meinst Du mit Array? Datenbanken können kurze oder lange Texte speichern, je nach Datentyp, den Du in der Tabelle vorher festlegst. Und zum Schluß: Es gibt eine kleine, low-traffic Mailinglist zum Thema Postgres: postgres-subscribe@yahoogroups.de HTH, trotz des bunten Durcheinanders, Helga -- ~~~~~~~~~~~~~~~~~~~~~~Wer macht mit?~~~~~~~~~~~~~~~~~~~~~ Das dt. Dokumentationsprojekt von OpenOffice.org sucht Mitstreiter # Projekt-Einstieg: http://lang.openoffice.org/de # Mailingliste: http://lang.openoffice.org/de/about-mailinglist.html
Moin,
* Helga Fischer
Hier kann ich eigentlich nur einen Abstecher in die MySQL-Ecke empfehlen, hier existiert ziemlich viel Thema, auch Grundlagen. Ich rate dringend ab. MySQL ist keine relationale Datenbank, in den entsprechenden Büchern dürfte also nicht viel zu holen sein.
Die SQL-Befehle erlauben Dir, Deine Datenbank anzulegen und darin dann die Tabellen einzurichten (create database, create table). Abfragen kannst Du das alles mit select ... from.
Für diese Operationen steht Dir eine Art Kommandozeile zur Verfügung, der bist Du vermutlich schon begegnet. Besser noch: Die Befehle in eine Datei schreiben und insgesamt ausführen lassen. Das vereinfacht die Fehlersuche.
Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde, nur steht in der Doku, dass Arrays meist auf schlechtes Datenbankdesign zurueckzufuehren sind. Was meinst Du mit Array? Datenbanken können kurze oder lange Texte speichern, je nach Datentyp, den Du in der Tabelle vorher festlegst. MySQL kann auch Sets, PostgreSQL IIRC nicht.
Und zum Schluß: Es gibt eine kleine, low-traffic Mailinglist zum Thema Postgres: postgres-subscribe@yahoogroups.de Es gibt auch pgsql-novice@postgresql.org, Motto: "No question is too simple here."
Thorsten -- When a thing has been said and said well, have no scruple. Take it and copy it. - Anatole France
Hi Thorsten, Am Sonntag, 2. Juni 2002 13:28 schrieb Thorsten Haude:
* Helga Fischer
[02-06-02 13:16]: Hier kann ich eigentlich nur einen Abstecher in die MySQL-Ecke empfehlen, hier existiert ziemlich viel Thema, auch Grundlagen.
Ich rate dringend ab. MySQL ist keine relationale Datenbank, in den entsprechenden Büchern dürfte also nicht viel zu holen sein.
Weiß ich, vergessen, darauf hinzuweisen. Es gibt Leute, die benutzen den relationalen Teil einer Datenbank nicht, auch wenn er vorhanden ist und machen alles mittels Programmlogik. Die MySQL-User müssen sich ja auch behelfen. Ansonsten gibt es überall die gleichen oder ähnliche Grundlagen, da muß man sich halt durchkämpfen. Das ultimate Datenbankbuch habe ich leider noch nicht gefunden.
Für diese Operationen steht Dir eine Art Kommandozeile zur Verfügung, der bist Du vermutlich schon begegnet.
Besser noch: Die Befehle in eine Datei schreiben und insgesamt ausführen lassen. Das vereinfacht die Fehlersuche.
Yo, sehr bequem.
Es gibt auch pgsql-novice@postgresql.org, Motto: "No question is too simple here."
Ah, das ist gut, ich hätte auch ein paar simple Fragen - mit simplen Englisch ;). Helga -- ~~~~~~~~~~~~~~~~~~~~~~Wer macht mit?~~~~~~~~~~~~~~~~~~~~~ Das dt. Dokumentationsprojekt von OpenOffice.org sucht Mitstreiter # Projekt-Einstieg: http://lang.openoffice.org/de # Mailingliste: http://lang.openoffice.org/de/about-mailinglist.html
Moin,
* Helga Fischer
Am Sonntag, 2. Juni 2002 13:28 schrieb Thorsten Haude:
* Helga Fischer
[02-06-02 13:16]: Hier kann ich eigentlich nur einen Abstecher in die MySQL-Ecke empfehlen, hier existiert ziemlich viel Thema, auch Grundlagen. Ich rate dringend ab. MySQL ist keine relationale Datenbank, in den entsprechenden Büchern dürfte also nicht viel zu holen sein. Weiß ich, vergessen, darauf hinzuweisen. Es gibt Leute, die benutzen den relationalen Teil einer Datenbank nicht, auch wenn er vorhanden ist und machen alles mittels Programmlogik. Die MySQL-User müssen sich ja auch behelfen. Klar, das geht ja auch oft, in den entsprechenden Büchern dürften aber eben mehr von diesen MySQL-Tricks stehen als von der ganz normalen Verwendung von Referenzen.
Ansonsten gibt es überall die gleichen oder ähnliche Grundlagen, da muß man sich halt durchkämpfen. Das ultimate Datenbankbuch habe ich leider noch nicht gefunden. Ich hatte 'leider' einen guten Lehrer für die Grundlagen, kenne also auch kein gutes Buch.
Thorsten -- Der Optimist ist in der Regel ein Zeitgenosse, der ungenügend informiert ist. - John B. Priestly
On Sun, Jun 02, 2002 at 01:28:51PM +0200, Thorsten Haude wrote:
Moin,
* Helga Fischer
[02-06-02 13:16]: Was meinst Du mit Array? Datenbanken können kurze oder lange Texte speichern, je nach Datentyp, den Du in der Tabelle vorher festlegst. MySQL kann auch Sets, PostgreSQL IIRC nicht.
Keine Ahnung was ein "Set" ist, aber postgreSQL kann auch ganz "gewöhnliche" Arrays wie man sie halt aus den diversen Programmier- sprachen kennt. (Ein Beispiel habe ich in einer Mail in diesem Thread gerade aufgeführt. mfg Martin Neuditschko
Moin,
* Martin Neuditschko
On Sun, Jun 02, 2002 at 01:28:51PM +0200, Thorsten Haude wrote:
* Helga Fischer
[02-06-02 13:16]: Was meinst Du mit Array? Datenbanken können kurze oder lange Texte speichern, je nach Datentyp, den Du in der Tabelle vorher festlegst. MySQL kann auch Sets, PostgreSQL IIRC nicht. Keine Ahnung was ein "Set" ist, aber postgreSQL kann auch ganz "gewöhnliche" Arrays wie man sie halt aus den diversen Programmier- sprachen kennt. (Ein Beispiel habe ich in einer Mail in diesem Thread gerade aufgeführt. Die kannte ich nicht, aber MySQL's Sets sind Typen, die funktionieren etwas anders.
Thorsten -- It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
On Sun, Jun 02, 2002 at 01:16:14PM +0200, Helga Fischer wrote:
Hallo Martin,
Am Freitag, 31. Mai 2002 11:16 schrieb Martin Neuditschko:
1: Eine Tabelle mit Serie, Titel und eine mit Serie, Author, Verlag 2: Eine Tabelle mit Serie, Titel, Verlag und Author, wobei "Titel" ein Array ist.
Du hast in Deinen Tabellen viel zu viele redundante Informationen.
1: ... und 2: ... gehoeren nicht zusammen. Es sind zwei verschiedene Ansätze.
Problem: Bei "1" haette die 1. Tabelle ziemlich oft den Namen der Serie gespeichter, was sich durch ein Array wie in "2" beschrieben umgehen lassen wuerde, nur steht in der Doku, dass Arrays meist auf schlechtes Datenbankdesign zurueckzufuehren sind.
Was meinst Du mit Array? Datenbanken können kurze oder lange Texte speichern, je nach Datentyp, den Du in der Tabelle vorher festlegst.
CREATE TABLE x1 { name text, titel[] text }; INSERT INTO x1 VALUES { "Serie1", { "Titel1", "Titel2" } }; INSERT INTO x1 VALUES { "Serie2", { "Titel1", "Titel2", "Titel2", "..." } };
Und zum Schluß: Es gibt eine kleine, low-traffic Mailinglist zum Thema Postgres: postgres-subscribe@yahoogroups.de
Danke für den Link. mfg Martin Neuditschko
participants (4)
-
Helga Fischer
-
Martin Neuditschko
-
Michael Raab
-
Thorsten Haude