MYSQL - wie strukturiere ich meine Datenbank?

[Chrsitian]

Für die Seite (www.barolino.ch/try) möchte ich eine Datenbank anlegen. Sie soll eine Liste von Bars enthalten, Links zu Bildern, Kommentar, Adresse etc..

Meine Fragen:

1. Wie strukturiere ich dies am besten? Ist es sinnvoll, alles in einer Tabelle zu haben?
2. Kann man nachträglich die Struktur der DB ändern? Neue Felder hinzufügen etc? Ich habe Angst dass ich die ganze Arbeit des erfassens ein Zweites Mal machen muss.

Grüsse
Christian

[Mike]

Moin Christian,

1. Wie strukturiere ich dies am besten? Ist es sinnvoll, alles in einer Tabelle zu haben?
2. Kann man nachträglich die Struktur der DB ändern? Neue Felder hinzufügen etc? Ich habe Angst dass ich die ganze Arbeit des erfassens ein Zweites Mal machen muss.

Hier ist immmernoch Papier und Stift dienlich:

Male es auf:

• Gibt es gleiche Beschreibungen?
• Gibt es gleiche Bilder
• Soll man danach suchen können? ( Wichtig für Indizes )

Wie gesagt, male es mal auf

Gruß
Mike

[Chrsitian]

Hm, ja ich probirs mal mit aufzeichnen. Ich habe es bis jetzt mal so aufgebaut.

id  varchar(12)
barname  varchar(50)
location  varchar(50)
portrait  text
adress  tinytext
add  text
homepage  tinytext
pic1  varchar(100)
pic2  varchar(100)
gallery   int(1)

[Tom]

Hello,

id  varchar(12)

Wenn nicht wichtige Gründe dagegen stehen, würde ich die ID immer
bigint() unsigned primary autoincrement (not null) definieren

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Chrsitian]

Danke Tom,
1.Was sollen eigentlich die Attribute (Unsigned,binary und zerofill)??
2.Und das "NULL" or "NOT NULL"?

[dbenzhuser]

N'Obend

2.Und das "NULL" or "NOT NULL"?

NULL: Feld darf frei bleiben
NOT NULL: Feld darf nicht frei bleiben

Tschö,
dbenzhuser

[Chrsitian]

Noch ne frage:
Was soll das mit dem "Primary"???

[Tom]

Hello,

Was soll das mit dem "Primary"???

Ein Primary Key ist ein Schlüsselfeld, dass den Datensatz eineindeutig kennzeichnet.
Das bedeutet, dass ein Datensatz genau einen Primary Key enthalten darf und einem Primary Key genau ein Datansatz zugeordnet ist.

Dafür darf die Schlüsselspalte keine Duplicates enthalten.
Der Einfachheit halber nimmt man deshalb einen Autoincrement-Key (wenn das DBMS den kennt), da er vom DBMS automatisch verwaltet wird. I.d.R. wird er pro insert automatisch hochgezählt. Einmal vergebene Schlüssel dürfen (eigentlich) automatisch auch nie wiederverwendet werden. Angeblich ist das aber bei MySQL nicht gewährleistet.

Primary Keys können auch zusammengesetzte Schlüssel und/oder Alphanumerische Schlüssel sein.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian]

Danke, jetzt habe ich wenigstens eine kleine Ahnung.
So, nun werde ich die Tabelle erstellen. Der Erste Eintrag ist die "id" welcher nicht 0 sein darf und mein Primary key ist. (wird automatisch durchnummeriert)
Hoffe es klappt.

[Andreas-Lindig]

Hallo Christian,

Noch ne frage:
Was soll das mit dem "Primary"???

Ich will ja nicht meckern, aber ich kann nicht nachvollziehen, daß Du mit diesen geringen Vorkenntnissen Dein Projekt in eine DB überführen willst. Du hast ja wirklich nicht die elementarsten Kenntnisse. Ich empfehle Dir ganz ernsthaft: lies erstmal was über DB, die Prinzipien, die Datentypen, mach ein paar Übungen und fang dann mit Deinem richtigen Projekt an, sonst passiert Dir genau das wovor Dir graut: daß Du alles nochmal machen mußt.

Ich empfehle wärmstens: ISBN 3 499 61222 4
Ein hervorragendes Einsteigerbuch für SQL und Datenbankentwurf, speziell mit mySQL-Syntax. Taschenbuch für 9,90 Euro.

Gruß, Andreas

[Tom]

Hello,

Ich empfehle wärmstens: ISBN 3 499 61222 4
Ein hervorragendes Einsteigerbuch für SQL und Datenbankentwurf, speziell mit mySQL-Syntax. Taschenbuch für 9,90 Euro.

Und schon mal ein Anfang http://www.techfak.uni-bielefeld.de/~walter/lehre/dm2/dbsql/

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Christian]

tja, danke an alle hilfsbereiten. Ich will ja auch nicht mekern. Denn jetzt habe ich eine Tolle Datenbank, welche ich morgen füllen werde und schon funzt est. Also jeder hat halt so seine kleine Problemchen. Meine waren vielleicht elementar, aber sie sind jetzt gelöst. Für sowas ist doch ein Forum da. Danke für den Buchtip. Werde mir schon mal ein Buch kaufen, allerdings kann ich mir das als Student eigentlich gar nicht leisten. Cheeers.
Christian

[Mike]

Moin Christian

1.Was sollen eigentlich die Attribute (Unsigned,binary und zerofill)??
2.Und das "NULL" or "NOT NULL"?

Unsigned bekommst du nur bei einer Zahl

Das kommt noch aus den Zeiten wo Speicherplatz rar war:
Damals ging integer so ungefähr bis 32.000, allerdings in beide Richtungen. Also von - 32.000 bis + 32.000. Wenn du nun unsigned sagst dann gibt es kein Vorzeichen, und schon ist dein Bereich bei 64.000 ( im Plus ) Binary, naja heißt Binärdaten ( wäre zB ein Blob ), wenn du Bilddaten speichern möchtest. Zerofill ( überfragt ) Not NULL = Muss dieses Feld einen Wert haben oder nicht. Wenn du ein Feld definiert hast mit "NOT NULL" und übergibst keinen Wert. dann gibt es einen Fehler.

Gruß
Mike

[Fabian St.]

Hi!

Danke Tom,
1.Was sollen eigentlich die Attribute (Unsigned,binary und zerofill)??

Unsigned bedeutet kein Vorzeichen, signed bedeutet vorzeichenbehafted.

So kann in C++ z.B. der Wert unsigned char die Werte von 0 bis 127, signed char die Werte -128 bis 127 haben, also immer genau 256.

Grüße,
Fabian St.

[Badboy46]

Hallo,

So kann in C++ z.B. der Wert unsigned char die Werte von 0 bis 127, signed char die Werte -128 bis 127 haben, also immer genau 256.

auch ne gute Rechnung *g*

[Christian Kruse]

Hallo Fabian,

So kann in C++ z.B. der Wert unsigned char die Werte von 0 bis 127,

Um genau zu sein, 0 bis 255 :)

Grüße,
 CK

[Fabian St.]

Hi!

So kann in C++ z.B. der Wert unsigned char die Werte von 0 bis 127,

Um genau zu sein, 0 bis 255 :)

Upps, sorry, da hab ich mich wohl ein wenig verrechnet *g*

Grüße,
Fabian St.

[Andreas-Lindig]

Hallo Tom,

Wenn nicht wichtige Gründe dagegen stehen, würde ich die ID immer
bigint() unsigned...

glaubst Du, daß die Schweiz 18446744073709551615 (sprich: achtzehntrillionenvierhundertsechsundvierzigbilliardensiebenhundertvierundvierzigbillionendreiundziebzigmilliardensiebenhundertundneunmillionenfünfhunderteinundfünfzigtausensechshundertundfünfzehn) Bars hat?

Ich vermute, soviele gibt's nicht mal in Düsseldorf ;-)

Gruß, Andreas

[Tom]

Hello,

Wenn nicht wichtige Gründe dagegen stehen, würde ich die ID immer
bigint() unsigned...

glaubst Du, daß die Schweiz 18446744073709551615 (sprich: achtzehntrillionenvierhundertsechsundvierzigbilliardensiebenhundertvierundvierzigbillionendreiundziebzigmilliardensiebenhundertundneunmillionenfünfhunderteinundfünfzigtausensechshundertundfünfzehn) Bars hat?

Ich vermute, soviele gibt's nicht mal in Düsseldorf ;-)

Aber vielleicht wechseln die so oft ihren Namen oder ihren Inhaber. Dann musst Du die Anzahl pro Jahr schon mal mit der Anzahl der Wechsel multiplizieren. Und wenn man solch eine Anwendung über 10 Jahre benutzen will, dann sollte man genügend Schlüsselvorrat für die Globalisierung berücksichtigen ;-))

Früher hatte der Bigint nur vier Bytes.
Ich bin mir nicht sicher, auf wieviele Bytes de mit MyISAM gewachsen ist. Nach Einsichtnahme in das Format mit einem Hexeditor denke ich, dass es jetzt sechs sind. Aber sicher bin ich nicht. Jedenfalls hat der interne Allkokationsschlüssel nur sechs Bytes. Das bedeuet also, dass man "nur" 2^(6*8) Bytes große Tabellen bauen kann.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Andreas-Lindig]

Aber vielleicht wechseln die so oft ihren Namen oder ihren Inhaber. Dann musst Du die Anzahl pro Jahr schon mal mit der Anzahl der Wechsel multiplizieren. Und wenn man solch eine Anwendung über 10 Jahre benutzen will, dann sollte man genügend Schlüsselvorrat für die Globalisierung berücksichtigen ;-))

Also, ich mach mal ne Beispielrechnung:
1. Die Schweiz hatte im Juli 2004 7.450.867 Einwohner
2. wenn _jeder_ Bürger eine Bar betreibt, und diese _jeden_ Monat Besitzer oder Namen wechselt, kommst Du in 10 Jahren auf den Faktor 120
3. das macht: 894.104.040 Datensätze in 10 Jahren. Mit Int Unsigned kommst Du schon bis auf über 4 Milliarden. Damit kannst Du die DB schon 40 Jahre betreiben (zu den oben genannten Voraussetzungen!). Bis dahin gibt es nicht mal mehr mySQL.

Früher hatte der Bigint nur vier Bytes.

alle meine Informationsquellen gestehen Bigint 8 Bytes zu.

Gruß, Andreas

[Tom]

Hello,

Also, ich mach mal ne Beispielrechnung:

1. Die Schweiz hatte im Juli 2004 7.450.867 Einwohner
2. wenn _jeder_ Bürger eine Bar betreibt, und diese _jeden_ Monat Besitzer oder Namen wechselt, kommst Du in 10 Jahren auf den Faktor 120
3. das macht: 894.104.040 Datensätze in 10 Jahren. Mit Int Unsigned kommst Du schon bis auf über 4 Milliarden. Damit kannst Du die DB schon 40 Jahre betreiben (zu den oben genannten Voraussetzungen!). Bis dahin gibt es nicht mal mehr mySQL.

Früher hatte der Bigint nur vier Bytes.

alle meine Informationsquellen gestehen Bigint 8 Bytes zu.

Nun habe ich nochmal gesucht. Ich schaue immer unter "Datentypen". Das heißt aber "Spaltentypen"
http://dev.mysql.com/doc/mysql/de/Column_types.html

Also ACK: MySQL-Integer wird wohl reichen => 31Bit Ganzzahl oder sogar 32Bit positive Ganzzahl. Aber auf die vier Bytes pro Datensatz wird es bei den heutigen Speichervolumina nicht ankommen, sodass es teurer sein wird, wenn man doch mal eines Tages umstellen müsste, aus welchem Grund auch immer. Da steckt bei mir also eher der Angstfaktor aus dem Jahr2000-Problem in den Knochen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Markus Pitha]

Hi,
Hier ein effizientes Datenmodell zu finden, dürfte nicht besonders schwer sein.
Grob gesagt könnte manes so machen:

Tabelle "bar":
barID, barname, bilder (Wobei ich nicht die Bilder an sich in die DB speichern würde, sondern nur Verweise), beschreibung, oeffnungszeiten, adresse.
(wobei barID ein Index mit auto_increment ist)

Tabelle "kommentare":
barID, username, kommentar.
(wobei in barID die ID-Nummer der barID der "bar" Tabelle gespeichert wird, um so die richtigen Kommentare zur richtigen bar zuordnen zu können.)

Markus.

[Christian]

(wobei in barID die ID-Nummer der barID der "bar" Tabelle gespeichert wird, um so die richtigen Kommentare zur richtigen bar zuordnen zu können.)

Hallo Markus:

Muss der BarID eine Nummer sein, oder kann es eine "Bezeichnung" (char) sein?

[Fabian St.]

Hi!

Muss der BarID eine Nummer sein, oder kann es eine "Bezeichnung" (char) sein?

IMHO muss BarID eine Nummer (also z.B. INT, oder TINYINT sein), wenn außerdem AUTO_INCREMENT gesetzt ist.

Grüße,
Fabian St.

[Christian]

Danke. Bringt mich wirklich weiter.
(ich weiss, einige fragen waren blöde, aber manchmal sind auch einfache Dinge schwierig rauszukriegen)