Reicht 1 Tabelle in Datenbank?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo an Alle,

ich beabsichtige einen Online-Shop zu programmieren.(PHP & MySQL)

Dazu habe ich mir überlegt:
-eine Tabelle Zugang, mit Benutzernamen und Passwort anzulegen und
-eine Tabelle Kundendaten, mit Vorname, Nachname, Straße usw. (natürlich noch weitere Tabellen mit den Produkten)

Beim Login des Kunden(durch Eingabe von Benutzernamen+Passwort) wird ja dann die MySQL Datenbank abgefragt, ob die Eingaben vorhanden sind und stimmen… wenn nicht soll der Kunde zur Eingabemaske zurückgeleitet werden.

Nach erfolgreichem Login des Kunden, soll dieser dann zu einer Übersicht seiner bisher gekauften Produkte usw. gelangen UND er kann durch Klicken auf „Kundendaten bearbeiten“ seine Daten wie Vorname, Nachname usw. löschen bzw. ändern.

Jetzt meine Frage: stört das die MySQL Datenbank dann wenn ich aus den 2 Tabellen eine mache?

MfG Sabine L.

#2

Ist vollkommen egal. Es kommt nur auf die Query drauf an. Du kannst ja auch Views benutzen!

Stefan.

#3

Danke!*G*
Vielen Dank Stefan!

MfG Sabine L.

p.s.was genau sind views?

#4

Vielen Dank Stefan!

MfG Sabine L.

p.s.was genau sind views?

Views (Sichten) sind in der Datenbank gespeicherte Abfragen. Komplizierte Abfragen, etwa mit mehreren Tabellen oder Berechnungen, werden als SQL hinterlegt. Statt jedes mal das aufwendige SQL Statement abzusetzen bietet es sich an, als View hierauf zurück zu greifen. Der View behandelt das Ergebis der Abfrage wie eine Tabelle, d.h. der View ist so etwas wie eine virtuelle Tabelle.
Im View kannst du SELECT /UNION/JOIN verwenden, nicht aber INSERT/UPDATE/DELETE.

Gruß Markus

#5

Ich würde aber vom konzepzionellen her lieber auf mehrere Tabellen gehn und mit Fremdschlüsseln arbeiten.

Dies verhindert unnötige Datenmengen und vereifacht abfragen, auch wenn diese dann über mehere Tabellen gehen.

Außerdem sollte dann die Performance wesentlich besser sein als bei aufgeblähten Tabellen.

mfg
Andreas

#6

Mh aber…
Dankeschön an Euch!

Fremdschlüssel ok … aber wie sieht das aus wenn ich eine Tabelle „Kunde“ und eine Tabelle „Produkte“ habe…

Muss ich die 2 Tabellen dann durch eine dritte(„Gekauft“) verknüpfen?

Dachte mir das so:

Im OnlineShop (Kunde bereits eingeloggt) sieht der Kunde eine Seite mit allen verfügbaren Produkten, die in einer Tabellenform angeordnet sind; die Datensätze werden aus der Datenbank geholt.

Des Weiteren gelangt der Kunde nach erfolgreichem Einloggen zuerst auf eine Seite, auf der er bereits gekaufte Artikel von ihm sehen kann.

Das heist doch also, es müssen einige Felder aus der Tabelle Kunde (Vorname, Nachname…) und einige Felder aus der Tabelle Produkte (Bezeichnung,ArtikelNr…) genommen werden und mir dann auf dieser Seite ausgegeben werden.

Und DAS sollte ich also mit Views machen ja…

Ach und wenn ich das ganze OHNE Views, sondern mit 3 Tabellen mache, bekomme ich dann ja den Fremdschlüssel oder?!

MfG Sabine L.

#7

hi!

Außerdem sollte dann die Performance wesentlich besser sein
als bei aufgeblähten Tabellen.

ähem, ich würde da persönlich lieber die „aufgeblähte“ tabelle mit vernünftigen indizes bevorzugen, als eine view über mehrere tabellen, wenn es um das thema performance geht … du mußt bedenken, daß die view bei jedem zugriff neu zusammengestellt wird - solange es sich nicht um eine materialized view vulgo „snapshot“ handelt

grüße,
tomh

#8

-/

wenn ich das richtig verstanden hab´ willst Du ALLE Daten in nur eine Tabelle schreiben.

Dazu gehört der Benutzername, Passwort, Post-ADRESSE, Email, und gekaufte Waren.

Angenommen, der Benutzer ändert sein Passwort oder Adresse; dies würde bedeuten, das Du alle Zeilen Updaten musst; bei einem guten Kunden vielleicht mehrere hunderte Zeilen.

Außerdem muss man mit einem Distinct auf die Tabelle gehen, wenn man nur die Benutzerdaten anzeigen will (ohne die Bestellungen) - sprich das Profil. Dabei sind sehr viele Datensätze zu überprüfen.

Man kann hier mit richtigen Indizies zwar schon eine gewisse (gute) Performance erreichen, aber wenn noch andere Abfragen laufen sollen, die nun nicht über diesen PK gehen, kanns problematisch werden.

Also ich persönlich würde ein Tabelle mit den Profildaten machen, eine Tabelle mit meinen Produkten und eine Tabelle mit der Zuordnung zwischen Benutzer und Produkten Beispiel:

Tabelle Benutzer:

BNZ_Benutzername (primary-key unique)

BNZ_strasse
BNZ_postleitzahl
BNZ_ort
BNZ_Emailadresse
BNZ_Passwort

Tabellen Produkte:

PRD_Nummer (primary-Key unique (fortlaufende ID))
PRD_Bezeichnung
PRD_Kategorie
PRD_verfügbar_ab
PRD_verfügbar_bis
PRD_Preis

Zwischentabelle: Aufträge

AUF_id (primary-Key uniqur (fortlaufende ID)
AUF_prd_nummer (FK)
AUF_BNZ_Benutzername (FK)
AUF_anzahl_artikel
AUF_gesamtpreis
AUF_Bestellt_am

…

Gruß
Andreas

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#9

Views sind nicht langsamer

Ich würde aber vom konzepzionellen her lieber auf mehrere
Tabellen gehn und mit Fremdschlüsseln arbeiten.

Daran hindert dich ja auch niemand.

Dies verhindert unnötige Datenmengen und vereifacht abfragen,
auch wenn diese dann über mehere Tabellen gehen.

Es gibt keine unnötigen Datenmengen. Ein View ist keine Kopie von Tabellen, es ist ein SQL Statement. Stell dir zwei Tabellen Rechnung und Posten vor, die in einer 1:n Relation stehen. Mit einem View verschmilzt du die Tabellen. Daten zu einer Rechnung rufst du mit „SELECT * FROM view WHERE RechNr=…“ ab.
Üblicherweise ist das ebenso effizient, wie die einzelne Abfrage zweier Tabellen.

Außerdem sollte dann die Performance wesentlich besser sein
als bei aufgeblähten Tabellen.

Da täuscht du dich:
1.) Ein Select auf einen View wird zusammen mit der WHERE-Clause ausgeführt, d.h. der View ist keinesfalls langsamer.
2.) Viele Client-Server Datenbanken hinterlegen Views vorkompiliert, d.h. das lästige SQL parsen entfällt hier.
3.) Die Abfrage einzelner Tabellen bedürfen jeweils eines SQL Statements, d.h. bei Zwei Tabellen musst du zwei SQL-Statements überragen, parsen und durch den Server beantworten lassen. Das sind zwei Roundtrips zum Datenbank-Server, beim View ist es nur einer.
4.) Durch die Verwendung von Views werden SQL-Statement kleiner, das spart bei langen Statements Netzbandbreite und reduziert den Parse-Aufwand.

Bei Desktop Datenbanken (Access) sind die Vorteile geringer, da es keine Netzwerkkommunikation gibt. Pauschal gesagt, sind sie aber nicht weniger Effizient.

Gruß Markus

#10

Außerdem sollte dann die Performance wesentlich besser sein
als bei aufgeblähten Tabellen.

ähem, ich würde da persönlich lieber die „aufgeblähte“ tabelle
mit vernünftigen indizes bevorzugen, als eine view über
mehrere tabellen, wenn es um das thema performance geht … du
mußt bedenken, daß die view bei jedem zugriff neu
zusammengestellt wird - solange es sich nicht um eine
materialized view vulgo „snapshot“ handelt

Hört sich an, als sprichst du über Oracle. Du solltest dir mal den Design&amp:stuck_out_tongue_winking_eye:erformance Guid durchlesen, Oracle hinterlegt den View nämlich
vorkompiliert. Insgesamt ist die View keinesfalls langsamer, sondern bei gut angelegten Indizes möglicherweise sogar schneller.
Bei „materialized views“ geht es um etwas ganz anderes, hier werden Daten zum schnellen Zugriff als Kopie abgelegt. Zum reinen lesen ist das sehr schnell, bei Schreibzugriffen aber eher problematisch.

Gruß Markus

#11

Ach und wenn ich das ganze OHNE Views, sondern mit 3 Tabellen
mache, bekomme ich dann ja den Fremdschlüssel oder?!

Der View dient dir lediglich als eine Art Sicht, d.h. du verwendest einen View um eine neue Sichtweise auf vorhandene Daten zu bekommen. Um Kunden mit Produkten in Beziehung stellen zu können, benötigst du eine neue Relation, die am besten durch einen weitere Tabelle umgsetezte wird:

Tabellen:

Kunden.KundenNr (unique key)
Kunden.Name
Kunden…

Produkte.Nr (unique key)
Produkte.Name
Produkte…

Gekauft.KundenNr ( unique
Gekauft.ProduktNr key )
Gekauft.Anzahl

Um zu Erfahren, was ein Kunde gekauft hat:

SELECT P.*
FROM Kunden K, Produkte P, Gekauft G
WHERE G.KundenNr = K.KundenNr AND P.Nr = G.ProduktNr

Markus

#12

ähem, ich würde da persönlich lieber die „aufgeblähte“ tabelle
mit vernünftigen indizes bevorzugen, als eine view über
mehrere tabellen, wenn es um das thema performance geht … du
mußt bedenken, daß die view bei jedem zugriff neu
zusammengestellt wird - solange es sich nicht um eine
materialized view vulgo „snapshot“ handelt

Hört sich an, als sprichst du über Oracle. Du solltest dir mal
den Design&amp:stuck_out_tongue_winking_eye:erformance Guid durchlesen, Oracle hinterlegt den
View nämlich
vorkompiliert. Insgesamt ist die View keinesfalls langsamer,
sondern bei gut angelegten Indizes möglicherweise sogar
schneller.
Bei „materialized views“ geht es um etwas ganz anderes, hier
werden Daten zum schnellen Zugriff als Kopie abgelegt. Zum
reinen lesen ist das sehr schnell, bei Schreibzugriffen aber
eher problematisch.

Gruß Markus

Also ich rede über Oracle und muss Markus recht geben. Dadurch das die vorkompiliert sind und entsprechend getraced sind views über mehrer Tabellen durchaus sehr performant - ebenso aber auch views auf große Tabellen (viele Spalten und Datensätze)

Man sollte aber nicht außer acht lassen, das man einfach Speicherplatz verschenkt, wenn man mit 1 oder 2 großen Tabellen arbeitet, da nicht immer alle spalten geüllt werden und der wert NULL auch speicherplatz benötigt.

Darüber hinaus ist es für Statistiken und SubSelects immer angenehm mit mehreren Tabellen zu arbeiten.

Im Endeffekt siehts ja so aus, das beide Wege nach Rom führen, und es einfach Geschmacksache ist, wie man damit umgeht.

Ich denke mal die Lösung mit mehreren Tabellen ist die sauberere und konzeptionell richtigt, die Lösung mit der Riesen-Tabelle und darübergelegte Views ist aber auch möglich.

#13

wenn ich das richtig verstanden hab´ willst Du ALLE Daten in
nur eine Tabelle schreiben.

nein,will ich nicht, will so wie du mehrere Tabellen machen :smile:
meine frage war nur, ob ich eine Zwischentabelle brauche, danke für die antwort,werde es so machen!

Tabelle Benutzer:

BNZ_Benutzername (primary-key unique)

BNZ_strasse
BNZ_postleitzahl
BNZ_ort
BNZ_Emailadresse
BNZ_Passwort

Tabellen Produkte:

PRD_Nummer (primary-Key unique (fortlaufende ID))
PRD_Bezeichnung
PRD_Kategorie
PRD_verfügbar_ab
PRD_verfügbar_bis
PRD_Preis

Zwischentabelle: Aufträge

AUF_id (primary-Key uniqur (fortlaufende ID)
AUF_prd_nummer (FK)
AUF_BNZ_Benutzername (FK)
AUF_anzahl_artikel
AUF_gesamtpreis
AUF_Bestellt_am

MfG Sabine L.

#14

THX!
aso,habs gecheckt.Dankeschön Markus! *g*

MfG Sabine L.

Der View dient dir lediglich als eine Art Sicht, d.h. du
verwendest einen View um eine neue Sichtweise auf vorhandene
Daten zu bekommen. Um Kunden mit Produkten in Beziehung
stellen zu können, benötigst du eine neue Relation, die am
besten durch einen weitere Tabelle umgsetezte wird:

Tabellen:

Kunden.KundenNr (unique key)
Kunden.Name
Kunden…

Produkte.Nr (unique key)
Produkte.Name
Produkte…

Gekauft.KundenNr ( unique
Gekauft.ProduktNr key )
Gekauft.Anzahl

Um zu Erfahren, was ein Kunde gekauft hat:

SELECT P.*
FROM Kunden K, Produkte P, Gekauft G
WHERE G.KundenNr = K.KundenNr AND P.Nr = G.ProduktNr

Markus

#15

huhuuu!
nich streiten ja *g*
wollte hier keine riesen diskussion entfachen :smile:
(typisch weiber ne)*fg*

MfG Sabine L.

#16

nich streiten ja *g*
wollte hier keine riesen diskussion entfachen :smile:
(typisch weiber ne)*fg*

MfG Sabine L.

Wieso streit ? das ist doch ein Diskussions-Forum und wir diskutieren :wink:

Man muss ja net immer die gleiche Meinung haben :o)

Das mit den Weibern stimmt aber trotzdem *gg*

Andreas

#17

Ahja, na ich sag jetzt mal lieber nix weiter dazu *gg*
Viel Spaß noch beim Diskutieren!

MfG Sabine L.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]