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?
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.
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?!
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
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:
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.
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&: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.
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:
ä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&: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.
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
meine frage war nur, ob ich eine Zwischentabelle brauche, danke für die antwort,werde es so machen!
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:
