Datenbank-Newbie Fragen...

blacksy

blacksy

Aktives Mitglied
Thread Starter
Dabei seit
14.12.2004
Beiträge
1.851
Reaktionspunkte
7
Hallo,

ich will mir ein kleines Webprojekt basteln und werde dieses mal wohl nicht drum herumkommen, mir das volle Programm mit PHP und MySQL zu geben. Ich habe was PHP und SQL angeht zwar "theoretische" Kenntnisse, aber das ist das erste mal, dass ich beides praktisch anwende(n will).

Daher ein paar, vermutlich sehr grundlegende, Fragen:

1. Ich stelle mir das doch richtig vor, oder? Ich habe eine Datenbank aus Tabellen, diese Datenbank wird mit MySQL verwaltet und die Datenbankzugriffe geschehen per PHP.

2. Wenn ich z.B. ein Gästebuch erstellen will, dann mache ich eine Tabelle mit "Entry" und den Spalten Entry_ID, Ersteller, Datum, Text, trage dort die entsprechenden Daten ein und parse die entsprechenden Postings dann mit jedem Aufruf per PHP auf die Page, oder? Oder bin ich da völlig auf dem Holzweg (wie gesagt, meine Kenntnisse sind rein theoretisch ;))

3. Gibt es eigentlich irgend eine prinzipielle Größenbeschränkung? Gibt es z.B. Probleme wenn die DB-Tabelle sehr groß wird? Also etliche zehn- und hunderttausend Einträge.

4. Ist es besser wenige Tabelle mit vielen Einträgen oder viele Tabellen mit wenigen Einträgen zu haben?

5. Wenn ich z.B. nen User mit Namen, Adresse, Gebursttag etc. erstelle, sollte ich dann "Adresse" als eigene Tabelle erstellen oder sollte ich alles in der selben Tabelle speichern? Ist es also besser eine Tabelle mit vielen Spalten zu haben oder sollte man nach Möglichkeit in verschiedene Tabellen auslagern. Hier auch wieder die Performancefrage.

Und dann:

6. Das Projekt ist verhältnismäßig umfangreich. Sollte ich das alles aufgrund meiner eher bescheidenen Vorlesungskenntnisse lieber lassen und gleich ein Content-Management System verwenden? Oder ist es besser, wenn ich das alles selbst programmiere? Wo sind die Unterschiede?

Es wäre mir nämlich schon wichtig, dass ich die volle Kontrolle über Layout und das Seitenkonzept habe und mich nicht - eventuell - nach möglichen Eigenarten des jeweiligen CM-Systems richten muss :eek:. Eben so, wie Wordpress-Blogs - aus irgend einem Grund - immer nach Wordpress-Blogs aussehen.

-
 
Zuletzt bearbeitet:
Hallo!
1.) Richtig!
2.) soweit im Ansatz richtig verstanden.
3.) lokale Größenbeschränkung ist die Größe der Festplatte ansonsten hängt es von Deinem Provider ab wie groß Deine Datenbank werden darf. Man sollte an dieser Stelle darauf hinweisen daß noch lange nicht alle webspace-Anbieter auch PHP und/oder MySql im Angebot haben .. insbesondere nicht bei den billigen Angeboten.
4. und 5.) Du hast ggf. wieder eine Grundatzdiskussion angezettelt... ich könnte jetzt mit Begriffen wie "kanonisch" und "Normalformen" kommen. Meine persönliche Meinung: Redundanzfrei aufbauen und sinnvoll gruppieren. Eine Adresse gehört in eine Tabelle. Über das Geburtsdatum könnte man da schon streiten weil ja nicht jede Adresse eine Person ist, könnte ja auch eine Institution sein, dennoch würde ich das mit da reinpacken. Beiträge zu einem Gästebuch oder, im kommerziellen Umfeld, Rechnungen eines Kunden würde ich natürlich immer in einer separaten Tabelle ablegen in der nur die "Adressnummer" drinsteht und nicht die ganze Adresse. Faustregel: Was ohne Redundanzen vom Business-Case her zusammengehört kommt auch in eine Tabelle.
Beispiel:
Kunden-Nummer, name, stasse, ort, telefon, fax => 1 Tabelle
Artikel-Nummer, Bezeichnung => 1 Tabelle
Rechnungs-Kopf: RG-Nummer, RG-Datum, Betrag, KD-Nummer => 1 Tabelle, aber halt OHNE Adresse des Kunden
Rechnungs-Positionen: RG-Nummer, Posnr, Artikelnummer, Menge, Preis, => 1 Tabelle, aber halt ohne Artikelbezeichnung
so etwa, ich hoffe Du verstehst was ich meine.
6.) Du wirst sehr viel Arbeit haben, dafür aber auch sehr viel lernen. Es wird aber auch sehr lange dauern bis Du ein Ergebnis hast, das mit den eher schnellen ersten Ergebnissen eines CMS konkurrieren kann.
Will sagen: es dauert bis Du etwas siehst.
Ansonsten hast Du die totale Kontrolle wenn Du es selber machst.
Ein prima Buch zu dem Thema ist übrigens "Web Database Applications with PHP and MySql" aus dem O'Reilly-Verlag (Das mit dem Schnabeltier...)
Da werden auch einige Themen angeschnitten, an die man zunächst als Einsteiger gar nicht denkt.
An Deiner Stelle würde ich mir aber dennoch die Mühe machen und auf jeden Fall ein Stück Deines Projekts durchprogrammieren, auch wenn die Finger wund werden und Du heulend vor dem Mac sitzt - nur um zu wissen wie es geh.
Viel Spaß.
 
falkgottschalk schrieb:
4. und 5.) Du hast ggf. wieder eine Grundatzdiskussion angezettelt... ich könnte jetzt mit Begriffen wie "kanonisch" und "Normalformen" kommen. Meine persönliche Meinung: Redundanzfrei aufbauen und sinnvoll gruppieren.(...)
Vielen Dank für deine schnelle Antwort :)

Mit Normalformen kenn ich mich ein wenig aus, aber es hätte ja sein können dass das bloß theoretische Konstrukte sind die in praktischen Anwendung keinen Platz haben weil z.B. Suchanfragen in zu großen Tabellen unverhältnismäßig lange dauern und man das in mehrere Tabellen splitten sollte, wenn möglich. Aber gut, ist nicht der Fall :D Dann weiß ich ja jetzt in etwa wie ich die Tabellen aufbauen soll :)


falkgottschalk schrieb:
An Deiner Stelle würde ich mir aber dennoch die Mühe machen und auf jeden Fall ein Stück Deines Projekts durchprogrammieren, auch wenn die Finger wund werden und Du heulend vor dem Mac sitzt - nur um zu wissen wie es geh. Viel Spaß.
Hmmh... Da werde ich vermutlich auch nicht drum herumkommen, da ein zentraler Teil der Page sicherlich nicht von den CMSen angeboten wird und selbst erstellt werden müsste. Geht das denn überhaupt, wenn man ein CMS verwendet?

Wie funktionieren diese Systeme denn? Sind das so Baukastensysteme wo man anklickt was man haben will (bzw. was angeboten wird) und die Software spuckt einem dann fertige Skripte aus? Oder ist das mehr eine Art "Entwicklungsumgebung" wie z.B. Dreamweaver, wo man zwar Tools bekommt um Standard-Operationen schnell zu implementieren, aber dennoch Kontrolle über den eigentlichen Programmcode hat und auch selbst programmieren kann, wenn es nötig ist?

PostNuke erschien mir ganz gut zu sein, da dort wohl mehr Wert auf Leichtgewichtigkeit gelegt wird als z.b. bei dem als sehr komplex bezeichneten Typo3. In jedem Fall soll das CMS aber lediglich eine grobe Grundlage sein, den wichtigen Teil will ich wie erwähnt auch selbst machen (können).
 
Am besten Du entwirfst die Datenbank erst einmal theoretisch, und normalisierst die erst einmal in die, wars die dritte Form? Ist schon lange her, kann das zwar noch aber die Bezeichnungen ... :D
Ne im Endeffekt ergibt sich aus der ganzen Aktion dann, wie Du die Tabellen in der Datenbank anlegen musst.
Selber machen ist eigentlich immer besser. Es gibt fertige CMS Systeme, die aber selten genau das bieten was man selber braucht. Erfahrungswert! Ein kleines CMS habe ich auch schon mal selber programmiert, wenn man mal drin ist in der Materie ist es halb so schlimm. Die Übung machts. :D
 
Wenn ich zum Beispiel ein Objekt habe und eine Person setzt nen Bookmark darauf. Wo Speicher ich die Bookmarks dann? Im Objekt oder bei der Person oder mach ich ne eigene Tabelle für Bookmarks?

Wenn ich ne Bookmarkliste mit Bookmark(Object_Id, User_ID) habe, dann wären das bei 1000 Leute mit jeweils 10 Bookmarks ja schon 10.000 Einträge. Und jedes mal wenn ich ne Select Anfrage starte, dann müsste ja diese riesige Tabelle ... *horror*. Oder unterschätze ich die Leistungsfähigkeit aktueller Server einfach gewaltig? Vermutlich schon, denn das "1107858" oben bei meiner Posting-ID hier im MacUser Forum lässt vermuten, dass man mit MySQL ohne weiteres Tabellen mit einer millionen Zeilen verwalten kann, oder irre ich mich da :eek:
 
Zuletzt bearbeitet:
Datenbanken sind dazu da große Datenmengen zu verwalten:)
Wenn's zu lange dauert sind Indizes angesagt. Generell gilt: normalisieren hilft viele Probleme vermeiden. Jedoch ist normalisieren nur um der Kunst wegen auch nicht immer gut. Es gibt Fälle in denen eine Redundanz zu erheblichen Geschwindigkeitsvorteilen führen kann. Hier verläßt der Pragmatiker den Weg der reinen Lehre - wenn auch auf eigene Gefahr :D
 
blacksy schrieb:
Wenn ich zum Beispiel ein Objekt habe und eine Person setzt nen Bookmark darauf. Wo Speicher ich die Bookmarks dann? Im Objekt oder bei der Person oder mach ich ne eigene Tabelle für Bookmarks?

Wenn ich ne Bookmarkliste mit Bookmark(Object_Id, User_ID) habe, dann wären das bei 1000 Leute mit jeweils 10 Bookmarks ja schon 10.000 Einträge. Und jedes mal wenn ich ne Select Anfrage starte, dann müsste ja diese riesige Tabelle ... *horror*. Oder unterschätze ich die Leistungsfähigkeit aktueller Server einfach gewaltig? Vermutlich schon, denn das "1107858" oben bei meiner Posting-ID hier im MacUser Forum lässt vermuten, dass man mit MySQL ohne weiteres Tabellen mit einer millionen Zeilen verwalten kann, oder irre ich mich da :eek:

Du unterschätzt die Fähigkeiten moderner Datenbanken. Als Beispiel nennen Wir nur ebay! Eine der größten Datenbanken der Welt.

Du brauchst eine Bookmarktabelle wo Du das Object_ID, User_ID speicherst.
Wenn Du mehr über Mysql wissen willst musst Du beim Hersteller nachlesen was die DB alles kann. ;)
 
Zurück
Oben Unten