uglygeorge08
-
Gesamte Inhalte
23 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Beiträge von uglygeorge08
-
-
Dies hatte ich dir aber schon beantwortet - und zwar HIER
Trigger!
Du kannst nicht auf ein INSERT reagieren, wenn du eigentlich was anderes meinst. (CONSTRAINT - FK [ForeignKey]).
Die DML sieht hier nur bei einem *UPDATE/DELETE* etwas vor - und zwar
a) den FK NULL werden lassen
den FK so lassen wie er istc) die Tupel löschen - mit dem betroffenen FK
d) abweisen von DELETE/UPDATE
Wenn du deine Frage explizit stellen würdest, käme die Antwort:
danke dir - der link sieht sehr gut aus.
hast mir sehr weitergeholfen, hätte aber nicht gedacht, dass man hierfür sogar einen Trigger verwenden muss ... :confused:
Gruss
ugly
-
Da ich eh grad lange Weile habe...
so ein paar kleine Sachen
1:1 Beziehungen machen nicht wirklich Sinn - in getrennte Tabellen zu speichern.
n:m Beziehungen kann man nicht so einfach Übernehmen (Chen ist zwar schön.. aber geht halt nicht) man muss jeweils in eine 1:n:1 auflösen. Kann man schön bei der MySQL-WB nachvollziehen.
In deinem konkreten Fall:
Der Benutzer = Relation 1
Die Sicherheitsfargen = Relation 2
Die Fragen = Tupel von Realtion 2
Die Antwort = Genau eine von einem Benutzer
Daraus ergibt sich follgendes:
Danke aber leider hast du überhaupt nichts von meinen Fragen beantwortet. Es geht hier nicht um das Datenbankbankdesign, sondern eher um eine simple frage: "Warum beim erstellen der Benutzer_ID", diese nicht in die Tabelle "Sicherheitsmassnahmen" übernommen bzw. eingetragen wird.
Bsp:
Tabelle Benutzer:
BenutzerID 1
Tabelle Sicherheitsdaten
Sicherheits_ID 1 | Passwort: test | Benutzername: test | BenutzerID (leer)
Klar könnte ich das ganze zusammenfassen, habe ich mir auch schon überlegt. Das ändert aber nichts an der Tatsache, dass es doch irgendwie umsetzbar sein sollte? :/
Diese 1 müsste doch auch in der Tabelle Sicherheitsdaten stehen?
Naja ... werd mich so oder so nochmals dami befassen, sonst komme ich hier glaubs nicht mehr weiter.
-
Danke dir - werd ich demfall noch ändern ...
Aber wenn ich zuerst einen Benutzer erstelle, trage ich einfach nix in die Tabelle ein?
Ich verstehe die Welt nicht mehr .. :/
Habe nun eine Tabelle "Benutzer". Mit nur einem Attribut, nämlich der Benutzer_ID. Erstell ich dort einen Eintrag, so übernimmt er die ID nicht in die Tabelle "Sicherheitsmassnahmen" und erstellt dort keinen leeren Eintrag mit der jeweiligen Benutzer_ID (als FK).
Ich denke das ich komplett etwas falsches erwarte bzw. ich mein Vorhaben komplett falsche umsetzte? :confused:
sorry für die vielen fragen, aber habe nun heute schon den ganzen tag an diesem Thema verbracht^^
-
Dein Datenmodell ist falsch. Der Benutzer hängt nicht an den Sicherheitsdaten sondern umgekehrt.
Also den Verweis zu den Sicherheitsdaten raus aus der Benutzertabelle und statt dessen einen Foreign Key in den Sicherheitsdaten zum Benutzer.
Dann hast auch dieses Henne Ei Problem nicht, denn der User wird zuerst angelegt und dann seine Sicherheitsabfragen - so wie man es auch in der Realität erwarten würde.
Dim
Danke dir - werd ich demfall noch ändern ...
Aber wenn ich zuerst einen Benutzer erstelle, trage ich einfach nix in die Tabelle ein?
-
P.S Das mit dem Trigger brauch ich momentan glaub weniger, da es sich im meinem Fall um den ersten Eintrag und kein "Update" handelt. Der Eintrag wird komplett neu erstellt.
sorry für dem double post - aber die editier Zeit war rum ^^
-
Was du denkst/meinst ist,
referentielle Integrität (r.I.)!
(Wenn ich die MySQL-WB sehe - gehe ich in der Annahme: MySQL!
Du musst dafür aber auch die InnoDB-Engine benutzen!)
Was du willst:
Trigger!
Noch was zu deiner Key-Frage.
r.I. bedeutet ja nicht - lege mir mal die Schlüssel in der anderen Tabelle mit an. Sondern: Prüfe ob es zu einem Konflikt kommt - und machen ein Rollback wenn nötig
.Weiter stellt die r.I. bei einem Insert (DML) ja auch nichts zur Verfügung.
Die einzigen die da ziehen sind: On UPDATE, ON DELETE.
Fragen?
Danke für deine schnelle Antwort. Wie du schon gesagt hast, verwende ich MySQL und InnoDB.
Das mit dem "Trigger" ist neu für mich, versteh ich bis jetzt noch nicht ganz, werd ich aber demfall noch bissel darüber lesen ..
Als Fazit können wir als nun sagen:
Das ich bei meinem PHP-Registrierungsskript zusätzlich ein SQL-Query erzeugen muss, welcher mir in der Tabelle Benutzer einen Eintrag erstellt?
Mein Ziel ist es:
Anhand einer Benutzer_ID x in der Tabelle Benutzer, alle Daten zu der Personen finden, sei es die E-Mail Adresse / Passwort oder die Adresse, welche ichj ebenfalls mit der Tabelle Benutzer verbinden werde.
Später komme noch Einträge hinzu, welche die Leute erstellen können. Diese sollten natürlich auch einem Benutzer zuweisbar sein ..
Ich stell mir nun die Frage:
Wie kann ich in die Tabelle "Benutzer" den Fremdschlüssen von der Tabelle Sicherheitsdaten übernehmen? ^^
Gruss
ugly
-
Hallo zusammen,
Wieder eine kleine Frage ..
Ausgangslage:
Eine Datenbank mit den beiden Tables "Benutzer" und "Sicherheitsdaten".
(In der Tabelle Benutzer habe ich 2 Keys abgedeckt ..
)
Fakten:
Mit meinem PHP-Registrierungs Skript wird in den Tabel "Sicherheitsdaten" das Passwort und die E-Mail Adresse reingeschrieben.
Frage:
Wenn in der Tabelle Sicherheitsdaten ein Eintrag erstellt wird, sollte dann nicht automatisch ein Eintrag in der Tabelle Benutzer erstellt werden?
Diese beiden Tabellen sind ja miteinander vernetzt und wie soll ich nun z.B eine Adresse, welche sich in einer anderen Tabelle befindet, mit den Sicherheitsdaten eines Benutzer verlinken?^^
Zusammengefasst:
Die Tabelle Sicherheitsdaten hat xx Einträge, aber die Tabelle Benutzer bleibt leer, obwohl dort die Sicherheitsdaten_ID übernommen werden soll.
Danke schon im voraus.
Gruss
ugly
-
Hallo,
ich probiere gerade einen SMTP-Server (Pegasus) einzurichten und scheitere am verbinden zum SMTP-Server von Hotmail.
Informationen:
Kostenloses POP3 für alle Hotmail-Konten - Windows Live
telnet smtp.live.com 25 --> error
ping smtp.live.com --> error
Firewall von Windows habe ich auch mal deaktiviert. Auf POP3 Server kann ich verbinden.
Einer eine Idee an was das liegen könnte?
Betriebssystem : Windows 7
danke & gruss ..
-
Da fallen mir direkt ein paar Sachen ins Auge:
1. Du solltest Dich bei der Tabellenbenennung für den Singular oder den Plural entscheiden, nicht mischen. Ich persönlich bevorzuge den Singular. Also z.B. statt dem Begriff Personalien das was auch drinnen steht also Person. Das aber nur als Vorschlag um die Lesbarkeit zu erhöhen.
2. Das momentane Alter unterliegt doch recht großen Schwankungen. Daher niemals das Alter, sondern immer das Geburtsdatum hinterlegen.
3. Die Tabelle PERSONALIEN ist die übergeordnete Tabelle. Also raus mit dem Feld IDAdresse. Die Beziehungsbeschreibung würde dann lauten: Eine Person hat eine, keine oder mehrere Adressen, eine Adresse ist genau einer Person zugeordnet. In die Tabelle ADRESSE kommt dann das Feld IDPERSONALIEN als Fremdschlüssel rein
Damit ist auch Dein Problem erledigt. Du trägst zuerst per PHP die Personendaten ein, dann die Adressdaten und anschließend COMMIT.
Ein FK bildet die Beziehung aber von unten nach oben ab, nicht von oben nach unten. D.h. die übergeordnete Tabelle kennt die untergeordnete erstmal nicht, die untergeordnete weiß aber über den Fremdschlüssel welche Tabelle ihr übergeordnet ist. Da hast Du einen ganz großen Denkfehler drinnen, der dann zu Deinem Problem führt.
Du hast jetzt eine 1:1 Beziehung. D.h. eine Person hat genau eine Adresse. Sofern das richtig wäre könnte man sich die zweite tabelle auch direkt sparen und alles in einer tabelle zusammenbauen (machen wir aber natürlich nicht, denn wir wollen für eine Person ja auch mehrere Adressen angeben können).
Augenscheinlich haben diesen Denkfehler aber wohl mehrere
Also ruhig nachmachen.Dim
Wow Dim - danke vielmals. War kurze Zeit in den Ferien, konnte deswegen das Forum nicht öffnen ..
Wie immer eine Top Antwort von dir.
Danke & Gruss
ugly
-
Was ich mich eh Frage ist, warum du diese Daten in zwei getrennten Tabellen erfasst... auch könntest du in der Adress-Tabelle die Personal-ID als Fremdkey nehmen und ggf. noch einen weiteren Index, falls ein Mitarbeiter mehrere Adressen haben können soll.
Hm ... meinst du? Die Adresse ist ja normalerweise ein Bestandteil der Personalien und nocht umgekehrt?^^
Ich habe das so durchgesagt:
Mehrere Personalien können eine Adresse haben. Eine Adresse kann zu mehreren Personalien gehören?
Jetzt versteh ich nur noch Bahnhof .. ^^
@ Lizzy:
In welchen Fällen würde es z.B Sinn ergeben, ein Fremdschlüssel nicht auf "NOT NULL" zu setzten?
Danke euch beiden & Gruss
Ugly
-
Hallo,
zu 1.) ja, da hast du Recht, dass musst du auf diesem Weg so machen und in dieser Reihenfolge.
Gruß
Oh okey, das hört sich umständlich an ....
Vielleicht sollet ich doch die eine oder andere 1:1 Verbindung einbauen. Beim User hatte ich das Problem, bevor er sich registrieren kann, muss er seine Personalien bis aufs detailierteste erfassen.
Zwischen dem Tabel User und Personalien habe ich nun neu eine 1:1 Relation. Da kann er nun die Personalien auch später erfassen ..
Danke für deine Antwort. Ich lasse den Thread mal für weitere Antworten, weiter bumpen ..
Gruss
ugly
-
Hallo zusammen,
Der nervige Junge mit den lästigen Fragen ist wieder zurück ..
Folgendes ist mir beim betrachten meines ERD"s aufgefallen:
Man nehme z.B:
Tabelle - Personalien
IDPersonalien
Geschlecht
Name
Vorname
Alter
IDAdresse
Tabelle - Adresse
IDAdresse
Strasse
Hausnummer
PLZ
Ort
In der Tabelle Personalien haben wir den Fremdschlüssel von der Tabelle "Adresse". Da wie wir alle wissen, die Adresse ein Bestandteil der Personalien ist.
Meine Frage an euch:
- Wie soll/kann ein User via PHP seine kompletten Personalien erfassen können?
Will er die Personalien erfassen, so scheitert es bei der Adresse, da diese noch nicht in dem Table "Adresse" erfasst wurde?
Die einzige logische Variante wäre, das man zuerst die Adresse erfasst bzw. zuerst in die DB schreibt und anschliessend den Rest der Personalien?
Ist das nicht ein bisschen umständlich oder gibt es da einen anderen Weg? Mir ist das per Zufall beim rumspielen mit meiner DB in den Sinn gekommen, obwohl ich noch keine Zeile PhP geschrieben habe.
Zusatzfrage (optional :floet: )
2. Kann mir jemand den Unteschied zwischen "nicht identifizierbaren" und "idenzifizierbaren" Relationen erklären? Habe nun sicher schon 3 Erklärungen erhalten, aber keine hat wirklich eingeleuchtet .. ^^
Am meisten Sinn würde es machen, wenn z.B ein User gelöscht wird, dass alle Datenzeilen derTabellen welche mit einer idenzifizierten Relation angesprochen werden, ebenfalls gelöscht werden. Natürlich nur die vom betreffenden User?
Ich hoffe ich gehe euch hier nicht zu fest auf die nerven ...
gruss & nice weekend
ugly
-
Letzteres wäre meine Wahl.
Bezüglich der Schemate: Ich bin im Schneeflockenschema zuhause. Reine OLAP Systeme habe ich bisher noch nicht designed.
Dim
Okey danke dir ..
-
Hey Dim,
War wieder mal zu langsam beim editieren ..
Zum nochmals deine Aussage zusammenzufassen, dü würdest also auf "identifizierte Relationen" verzichten und alles mit eindeutigen PK"s machen?
Sprich bei einer N-M Beziehung anstatt:
Bold = FK
Unterline = PK
Das erste Beispiel wäre mit itendifizierten und das zweite mit non - identifizierten Relationen ..
Gruss
Ugly
-
Hmm ich hab die Begriffe so noch nie gehört, gehören wohl eher in die theoretische Abteilung
Das ist der Normalfall. Der PK der übergeordneten Tabelle wird als FK in der untergeordneten abgelegt.
Kann man machen, ich würde aber davon abraten einen PK gleichzeitig auch als FK zu verwenden. Zum einen könnest Du Probleme bekommen, wenn doppelte Einträge vorhanden sind (ein PK ist immer Unique) zum anderen macht es die Sache m.M. nach unübersichtlicher. So knapp sind wir nicht an Spalten und dieses Vorgehen erinnert mich an den Code, den diverse "Gurus" in ihren Programmen hinterlassen (Variablen haben grundsätzlich nur einen Buchstaben, alles was nicht unbedingt sein muss wird weggelassen. Sieht cool aus, kann nur keiner mehr lesen). Wir machen sowas natürlich nicht, sondern legen eine eigene Spalte für den PK an.
Da Du hoffentlich für einen PK immer ein rein technisches Feld ohne jeglichen fachlichen Bezug verwendet hast, kommst Du überhaupt nicht in diese Verlegenheit. Verwende als PK immer eine laufende Nummer (generiert von der DB per Sequenze, AutoInc) oder eine GUID. Möglich wäre auch, ein per Definition eindeutiges fachliches Feld zu verwenden und dieses in der Tabelle zu doppeln.
Beispiel: Die Sozialversicherungsnummer ist eindeutig. Dann hast Du ein Feld ID für den PK und ein Feld SOZVERSNR, welche mit identischen Werten bestückt werden.
Kann manchmal ganz nützlich sein, wenn man als Entwickler "weis", dass der PK einen gewissen fachlichen Hintergrund hat. Im Programm selbst wird natürlich nur die SOZVERSNR an die Oberfläche geliefert, die ID wird lediglich im Hintergrund verwendet.
Schema? Du meinst den Hersteller? Fast ausschließlich Oracle.
Dim
Hallo Dim,
Und wiedermal hast du mir wieder aus der Schlinge geholfen ..
Mit den Schemen meinte ich folgendes:
Schneeflockenschema:
Schneeflockenschema ? Wikipedia
Sternschema:
Gruss
Ugly
-
Jetzt liegt mir schon wieder die nächste Frage auf den Lippen ... :hells:
Und zwar geht es dieses mal um den Unterschied von "idenzifizierten" und "nicht identifizierten" Relationen.
Gewisse Dinge konnte ich schon herausfinden:
- identifizierte Relationen geben die ebenfalls idenzfizierten Schlüsse der Tabelle an die nächste weiter.
- werden bei der n - m Beziehung angewendet, bei welcher der Primärschlüssel, zugleich dem Fremdschlüssel entspricht.
- werden dann angewendet, wenn man nur mit deinem Primärschlüssel den Datensatz nicht eindeutig idenzifizieren kann?
Habe diverse Erklärung zu diesem Thema durchgelesen, aber wirklich auf die Sprünge geholfen hat es mir nicht.
Wenn es dir nichts ausmacht, könntest du mir das an einem einfachen Beispiel erklären?
Ich hoffe das ich dir nicht auf die nerven gehe. Ich möchte einfach ein wirklich gutes ERM für meine Homepage erstellen, damit ich es zu einem späteren Zeitpunkt nicht bereue ....
achja ... mit welchen Datenbankschemen hast du in Vergangenheit eigentlich gearbeitet?
Gruss
Ugly
-
Da gibt es eigentlich keine Balance zu finden. Was gebraucht wird, wird angelegt. Einer Datenbank ist es egal, ob sie 100 oder 120 Tabellen beinhaltet. Das macht auch die Administration nicht einfacher oder schwerer.
Das kann man als Lookuptabelle durchaus so machen (um z.B. einen eingegebenen Strassennamen zu prüfen) abspeichern würde ich das aber immer als Klartext in der entsprechenden Tabelle. Sprich Du hast als Stammdaten z.B. eine Tabelle mit PLZ und Strassennamen, eine mit Vorwahlnummern etc. aber wenn der User dann seine Adresse wirklich eingegeben hat, wird der, vorher anhand der Stammtabellen verifizierte Inhalt, im Klartext in die Adresstabelle geschrieben.
Speicherplatz ist billig. Eine zu langsame Datenbank nicht. Wieviel GB benötigt man, um 10 Millionen Adressdaten zu speichern? Wenn man mal von, sagen wir 500 Byte pro User ausgeht, dann würden 10 Millionen auf ~5GB kommen - also nix. Wenn ich das jetzt auf 2GB drücken kann, weil ich extrem normalisiert habe, spare ich mir wieviel Euro?
Dagegen stehen dann eine deutlich verschlechterte Performance, weil meine SQL Statements für jeden Zugriff noch über weitere Tabellen joinen müssen, ausserdem erhöhter Entwicklungsaufwand, denn jede zusätzliche Tabelle erhöht die technische Komplexität - bei gleicher fachlichkeit des Programms.
Grundsätzlich geht man so heran, dass man zuerst mal ein ER-Modell designed, welches die Anforderungen an Daten und Flexibilität erfüllt - dazu ist selbstverständlich eine genaue fachliche Anforderung nötig. Dieses ER-Modell liegt dann in der 3. NF vor. Jetzt beginnt man gezieht zu denormalisieren d.h. Redundanzen einzubauen, um Zugriffe zu beschleunigen und die Entwicklung zu vereinfachen. Das ganze ist natürlich auch Übungssache, wie auch beim Autofahren so wird aus des Modellieren mit der Zeit besser werden (zumindest bei den meisten...)
Keine Ahnung. Ich bin nicht mal bei facebook angemeldet geschweige denn, dass ich irgendeine Ahnung von deren Datenmodell hätte. Webdatenbanken sind aber allgemein eher stärker denormalisiert, da es im Netz nix schlimmeres gibt als eine Wartezeit länger als 2 Sekunden. Dazwischen gibt es selbstversändlich noch Proxies, die Abfragen cachen, Loadbalancer etc. etc. um die Last auf die Datenbanken so gering wie möglich zu halten.
Das Problem hast Du doch überall. Dazu gibt es Tabellen- und Spaltenkommentare, die in der DDL eingefügt werden können (je nach Datenbank ist die Syntax unterschiedlich) und zum anderen natürlich eine Dokumentation des Modells in Prosa bzw. über Constraints (die Benutzer_id wird vermutlich einen FK-Constraint auf die Benutzertabelle haben).
Dann weißt Du auch noch in einer Woche, dass dieses Feld die Benutzertabelle referenziert. Wenn Du aber nicht mehr sicher bist, warum das nötig war solltest Du dir die Anforderung nochmal durchlesen
Dim
Wow besten Dank für deine top ausführliche Antwort ..
Falls ich mich mal revanchieren kann, einfach melden .. ^^
Gruss
Ugly
-
Danke Dim,
Du hast mir schon ernorm geholfen und man sieht das du auf diesem Gebiet ein grosses Know-How hast ..
Ich finde bei einem ERM ist es saumässig schwer, eine Balance zwischen "wenig Tabellen" und "gute Administration" zu finden.
Momentan bin ich soweit, dass ich sogar Strassen in eine neue Tabelle packe und so fast nur mit Primär und Fremdschlüssel arbeite.
Auf der einen Seite würde das bei vielen Nutzern sicher Speicherplatz sparen und die Administration erleichtern.
Leider habe ich jetzt aber von dir erfahren, dass dann die Datenbank länger für die Verarbeitung der Daten benötigt.
Gibt es eine Grundregel wie man diesen Spagat zwischen "schnelle DB" und "wenig Speicherplatz / leichte Administation" lösen kann?
Wichtig ist wahrscheinlich auch die Anzahl User welche dann auf die DB zugreifen werden, Facebook wird wahrscheinlich mit Sicherheit auch Namen, Strassen etc in eine neue Tabelle verpackt haben?
Nichts destotrotz danke ich dir für deine Hilfe, dann werde ich das ganze mal wieder ein bisschen umstrukturieren ... ^^
Achja vielleicht kannst du mir auch diese Frage beantworten:
Du hast mir gesagt, dass eine Menge an Tables nicht gut sei, aber ich vermute dass du da die Relationen zu den Entitäten gemeint hast? Schlussendlich wird die die Tabelle Adresse ja keinen Einfluss z.B auf das Wetter haben ...
okey okey - wenn ich keine lokale Prognose möchte .. ^^
Frohe Weihnachten & Gruss aus der Schweiz
Ugly
Konnte leider nicht mehr reineditieren.
"2. Ich habe eine Tabelle "Benutzer", jetzt habe ich aber ein Attribut in einer anderen Tabelle mi dem Namen "Letzte Antwort", welches auf einen Benutzer verweist.
z.B Die letzte Antwort bei diesem Thema hat der "Benutzer A" gemacht. Verlinke ich nun die Benutzer_ID von der Entität Benutzer in die Tabelle "Einträge", so erscheint dort logischerweise die "Benutzer_ID. Wie soll ich aber in einer Woche noch wissen, dass die Benutzer_ID für die letzte Antwort steht und nicht für was anderes?^^
Benutzer_ID ist ja nicht sehr eindeutig, was die Aussage betrifft. Soll ich da eine neue Tabelle "Letzte Antwort" erstellen und sie mit dem Benutzer verlinken? Eventuell noch das Datum hinzufügen? oder Ebenfalls von der Tabelle Datum verlinken? ^^"
Gruss
Ugly
-
Die Adresse kommt in eine eigene Entität, die Personendaten ebenfalls. Weiter würde ich das nicht mehr trennen, denn ansonsten wäre es viel zu langsam hier die Daten wieder zusammenzusuchen.
Das was sie macht. Wenn z.B. ein Artikel und eine Rechnung eine n:m Beziehung aufweisen, dann ist die Verknüpfungstabelle eben die Bestellposition.
Die Namen sind egal, die Anzahl der Tabellen auch. Wenn Du 1000 brauchst, dann brauchst Du eben 1000. Wenn Du aber eine Beziehung mit 3 Tabellen beschreiben kannst, es ohne Not aber mit 7 machst, dann wird das Deine Performance deutlich beeinflussen sobald Last auf die Maschine kommt und die Tabellen mit Daten befüllt werden.
Dim
Danke Dim,
Du hast mir schon ernorm geholfen und man sieht das du auf diesem Gebiet ein grosses Know-How hast ..
Ich finde bei einem ERM ist es saumässig schwer, eine Balance zwischen "wenig Tabellen" und "gute Administration" zu finden.
Momentan bin ich soweit, dass ich sogar Strassen in eine neue Tabelle packe und so fast nur mit Primär und Fremdschlüssel arbeite.
Auf der einen Seite würde das bei vielen Nutzern sicher Speicherplatz sparen und die Administration erleichtern.
Leider habe ich jetzt aber von dir erfahren, dass dann die Datenbank länger für die Verarbeitung der Daten benötigt.
Gibt es eine Grundregel wie man diesen Spagat zwischen "schnelle DB" und "wenig Speicherplatz / leichte Administation" lösen kann?
Wichtig ist wahrscheinlich auch die Anzahl User welche dann auf die DB zugreifen werden, Facebook wird wahrscheinlich mit Sicherheit auch Namen, Strassen etc in eine neue Tabelle verpackt haben?
Nichts destotrotz danke ich dir für deine Hilfe, dann werde ich das ganze mal wieder ein bisschen umstrukturieren ... ^^
Achja vielleicht kannst du mir auch diese Frage beantworten:
Du hast mir gesagt, dass eine Menge an Tables nicht gut sei, aber ich vermute dass du da die Relationen zu den Entitäten gemeint hast? Schlussendlich wird die die Tabelle Adresse ja keinen Einfluss z.B auf das Wetter haben ...
okey okey - wenn ich keine lokale Prognose möchte .. ^^
Frohe Weihnachten & Gruss aus der Schweiz
Ugly
-
-
zu 2.
die relation ist 1:n
ein user kann viele einträge machen; ein eintrag kann nur von genau einem user gemacht werden.
zu 3.
genau so, wie du es getan hast:
>>user<<, >>eintraege<< --> T_user_eintraege
Danke du hast mir schon enorm geholfen ..
Ich will euch ja nicht nerven, aber vielleicht wisst ihr auch folgende Frage:
Facebook hat ja xxx Millionen Kunden welche alle ihre Daten wie Name, Vorname, Strasse, Hausnummer angeben.
Es wäre also nicht falsch bei einer Entität "Adresse", für alle Attribute (Vorname, Nachname, Strasse, PLZ, Ort) eine eigene Entität zu machen?^^
Bsp:
Adresse:
AdresseID
Name_ID
Vorname_ID
Strasse_ID
Name
NameID
Name
Vorname:
Vorname_ID
Vorname
Für die Relation verwende ich eine "nicht intenfizierte" Verknüpfung". Ergibt das soweit einen Sinn?^^
Wenn man das hochrechnen würde, so könnte man doch blöd viel Speicherplatz sparen?
Danke dir für deine Hilfe.
Gruss
Ugly
-
Hallo zusammen,
Für eine Homepage starte ich gerade den Versuch, ein doch eher grösseres ERM zu erstellen. Leider sind mir trotz vielen Hilfeseiten und Büchern noch diverse Fragen offen ..
Hier ein kleinen Überblich über meinen Fragekatalog:
1. Was ist in erster Linie das Ziel eines ERM?
Mir ist durchaus klar, dass es die Datenbankstruktur darstellen sollte, aber wie kann man z.B ein gutes ERM von einem schlechten unterscheiden?
- möglichst wenig Tables?
- keine redundanz an Attributen?
- gute visuelle Überschaubarkeit?
Kann man auch indirekt Einfluss auf die Geschwindigkeit einer Datenbank haben (zuviele tables, zu lange Namen).
2. Welche Relation würdet ihr in folgendem Beispiel verwenden, wenn auf einer Homepage, diverse User, diverse Gästebucheinträge machen können?
[user]-||-----|<- [Einträge]
oder
[user]||-----|< [user_Einträge] >|-----||[Einträge]
a) (1 - n) Ein User kann einen oder mehrere Einträge machen.
(n - m ) Ein oder mehrere User können einen oder mehrere Einträge machen.Für mich persönlich hört sich beides logisch an?
3. Wie beschreibt ihr bei einer Zwischenentität die Tabelle? Ich habe hier enorme Probleme, einen passenden Namen zu finden ...
Ich danke euch schon im voraus für euren Aufwand und bin für jeden noch so kleinen Hinweis unendlich dankbar ..
Schöne Festtage.
Gruss
Uglygoerge08
Warum erstellt er mir keinen Eintrag in diesem Tabel auf der Datenbank?
in Datenbanken
Geschrieben · Bearbeitet von uglygeorge08
Genau diese Funktion ermöglicht mir schlussendlich das vernezten der beiden Tabellen. Das habe ich gesucht ..
Dann wird die ID 1 von der Tabelle Benutzer genommen und anschliessend in die Tabelle Sicherheitsdaten bzw. dem Attribut SicherheitsdatenID eingetragen.
Grosses Kompliment an dieses Forum - wirklich grosses Kino was ihr hier liefert ..
Werds heute bzw- morgen Abend gleich mal in PHP umsetzen.
gruss
ugly
hehe okey ..