nicht angemeldet
auto_increment und LAST_INSERT_ID()
Hallo,
ich habe 2 MySQLTabellen in einer Datenbank. Dort sind jede Menge Attribute gespeichert, sowie z.B. Objektname, Preis usw..
Beide Tabellen haben als "PrimaryKey" die ObjektID, die auto_increment ist.
Wenn ich ein neues Objekt einfügen will muß ich ja beide Tabellen füllen und beide sollten dieselbe ID haben.
Dazu habe ich mir überlegt die erste Tabelle zu füllen und dann für das füllen der 2.Tabelle mit LAST_INSERT_ID() die ID zu bekommen die ja als auto_increment Wert mir nicht bekannt ist.
Ist das ein richtiger Lösungsansatz, oder kann es zu Problemen führen, wenn z.B. 2 Datenbankeinträge gleichzeitig stattfinden?
mfg
hulk
-
yo,
Ist das ein richtiger Lösungsansatz, oder kann es zu Problemen führen, wenn z.B. 2 Datenbankeinträge gleichzeitig stattfinden?
die erste frage, die sich stellt, warum du zwei tabellen brauchst. und wenn das unumgänglich ist, ja last_insert_id ist meiner meinung nach ein guter ansatz.
Ilja
-
Hallo,
die erste frage, die sich stellt, warum du zwei tabellen brauchst. und wenn das unumgänglich ist, ja last_insert_id ist meiner meinung nach ein guter ansatz.
Ilja
Also es gibt verschiedene Arten von Objekten, die gemeinsame Attribute haben aber auch verschiedene. Die gemeinsamen Attribute sind in einer Tabelle und die unterschiedlichen habe ich in jeweils eine andere Tabelle gepackt.
Ist das falsch?
mfg
hulk
-
yo,
Ist das falsch?
schwer zu sagen, ohne mehr infos zu haben. aber was du so beschreibst hört sich ziemlich schräg, wenn nicht falsch an. schlechtes datenbanbkdesign bringt oft folgeprobleme mit sich.....
Ilja
-
Hallo,
also ich habe eine Tabelle die objektid, objektname, objektueberschrift und noch ein paar Sachen enthält.
Es gibt 7 verschiedene Arten von Artikelgruppen , die einige Eigenschaften gemeinsam haben (alle in der eben beschriebenen gemeinsamen Tabelle). Es gibt aber auch verschiedene Attribute. Sowie z.B ein CD-Rohling in einem Online-Shop kein Tabellenfeld(Attribut) "Farbe" hat. Deshalb habe ich mir überlegt für jede Gruppe jeweils noch eine zusätliche Tabelle anzulegen mit individuellen Attributen.Ist das schlechtes Datenbankdesign?
mfg
hulk
-
yo,
Ist das schlechtes Datenbankdesign?
in dem falle ja. du solltest die objekte mit unterschiedlichen attributen sauber voneinander trennen, auch wenn sie gleiche spalten besitzen wie zum beispiel preis oder lagerbestand. mach einfach für jedes objekt, dass sich in den attributen unterscheidet eine extra tabelle.
Ilja
-
in dem falle ja. du solltest die objekte mit unterschiedlichen attributen sauber voneinander trennen, auch wenn sie gleiche spalten besitzen wie zum beispiel preis oder lagerbestand. mach einfach für jedes objekt, dass sich in den attributen unterscheidet eine extra tabelle.
Ilja
Hallo,
Aber warum, es sind 21 attribute die gleich sind. Damit mache ich mir doch unnötig viel Arbeit, wenn ich dieselben attribute in 7 Tabellen aufführe, oder?
Habe ich ein Risiko übersehen, oder warum ist es besser diese Attribute sauber zu trennen?mfg
hulk
-
yo,
Aber warum, es sind 21 attribute die gleich sind. Damit mache ich mir doch unnötig viel Arbeit, wenn ich dieselben attribute in 7 Tabellen aufführe, oder?
die "mehrarbeitet" betrifft nur den anfang und zahlt sich später aus was performance, flexibilität und fehleranfälligkeit betrifft. die frage ist, warum gleichen sich soviele attribute, bzw. wieviele glichen sich nicht. out of the head ist es schwer, deine datenbank design zu beurteilen. aber nur weil ein objekt zum teil gleiche attribute hat, ist es noch lange keine gute idee, sie zusammen zu führen, hauptsächlich aus dem grund, weil die daten der unterschidlcihen objekte nchst miteinander zu tun haben. du würdest dan eine tabelle führen, wo daten von ganz unterschidlcihen objekten drinne stehen. und das kann nicht gut gehen. selbst objekte mit genau den gleichen attributen werden voneinander getrennt, wenn sie in keiner beziehung zueinander stehen, zum beispel die kundetabelle von fleicher mesiter wird nicht zusammen in einer tabelle stehen mit dem gemüsehändler...
Ilja
-
out of the head ist es schwer, deine datenbank design zu beurteilen.
Das stimmt wohl, am besten ich beschreibe dies mal genauer. Es Handelt sich um eine Datenbank für Immobilien.
Es können verschiedene Arten von Immobilien eingepflegt werden. Häuser zum Kauf, Häuser zur Miete, Wohnungen zum Kauf....
Nun haben alle diese Immobilien 21 gleiche Felder(objekt_name, objekt_ort, objekt_postleitzahl...) aber es gibt eben auch Attribute und Werte die nicht jedes Objekt hat. z.B. ein Haus zum Kauf hat nicht das Feld "objekt_mietpreis". Zwar hat ein Haus zur Miete und auch eine Wohnung zur Miete dieses Feld aber halt nicht alle Objekte. Deshalb habe ich die gemeinsamen Werte zusammengeführt und die unterschiedlichen Werte in jeweils eine andere Tabelle (hauskauf, hausmiete, wohnungkauf,...) geschrieben. Diese Tabellen sind mit der objekt_id verknüpft und werden über einen Adminbereich per Formular gefüllt und da jedes Fromular quasi 2 Tabellen füllen muß hat sich mir die Frage mit dem last_insert_id() gestellt, da die objekt_id auto_increment ist.
Scheinbar schein aber an dem Datenbankmodell schon einiges zu hinken.
Wie ist es denn wenn ich einfach alle Attribute in eine Tabelle schreibe und dann einfach nur die benötigten fülle?
Aber das hat dann wohl nichts mehr mit einer relationalen Datenbank zu tun.
Aber die gemeinsamen Werte in vielen verschiedenen Tabellen immer wieder zu wiederholen scheint mir auch sehr Redundant.mfg
hulk
-
yo,
in der theorie trennt man was nicht zusammen gehört (normalisierung), sag ich mal so salopp. nun ist die theorie nicht immer das gelbe vom ei, letztlich soll es sich ja in der praxis bewähren und laufen und zwar auf deine bedürfnisse optimiert. deswegen muss man von fall zu fall sehen, was gut ist.
mein erster vorschlag wäre, alles zu trennen, was nicht zusammen abgefragt wird, selbst wenn sie haargenau die gleichen attribute hätten und natürlich auch bei unterschiedlichen attributen. mir fällt jetzt kein wirklich gutes beispel ein, aber ich sage mal, wenn du ganz sicher weißt, dass die mietshäuser in berlin niemals mit den mietshäusern in münschen zusammen abgefragt werden, könnte man diese trennen. das hängt sicherlich auch immer ein wenig von der anzahl der tabellen ab. es würde nun wiederum keinen sinn machen, für jede stadt eine eigene tabelle zu haben. man muss da den goldenen mittelweg finden. diese aufteilung macht sinn, wenn man eine grosse anzahl von datensätze hat.
der zweite vorschläg wäre, genau das gegenteil zu tun, alles in eine tabelle zu schreiben, so wie du es selbst beschrieben hast und dann einfach bestimmte felder leer zu lassen. außerdem führt man noch eine zusätzliche spalte ein, welche die unterschiedlichen objekte klassifiziert, zum beispiel M für mietshaus, etc. dies ist zum beispiel eine gute lösung, wenn du nicht all zuviele datensätze (immobilien) hast und somit die geschwindigkeit sowieso hoch ist und sich der verwaltungsaufwand durch eine tabelle niedrig halten läßt.
das was du machst, die gemeinsamen attribute in einer tabelle verwalten und die speziellen in extra tabellen, dass würde ich nicht tun. die performance wird schlechter und auch die verwaltung dürfte nicht einfacher werden, eher im gegenteil, der aufwand wird größer, weil man ja immer mehrere tabellen ansprechen muss. selbst speicherplatz wird daurch nicht weniger. es gibt zwar fälle, wo man die attribute einer tabelle voneinander trennt. das hat aber anderen ursachen, weil man attribute die selten abgefragt werden, von den attributen die häufig abgefragt werden trennt, um die performance zu erhöhen, zumal das auch nicht jedes dbms mitmacht.
Ilja
-
Hallo,
danke erstmal für deine ausführlichen Antworten und das du dir noch ältere Beiträge anschaust.
Um die Objektarten zu unterscheiden habe ich natürlich in der gemeinsamen Tabelle ein Feld objekt_category, das die Gruppe über eine andere Tabelle identifiziert.
Hast aber auch irgendwie Recht mit deiner Argumentation, die Hauptursache das ich die gemeinsamen Felder in einer Tabelle vereine ist wohl, das der Administrationsbereich sehr umfangreich ist und dort hauptsächlich die gemeinsame Tabelle abgefragt wird zum Anzeigen des Objektnamens oder der ObjektID.
Außerdem gibt es sowohl im Administrationsbereich als auch im Frontend(eine Website) eine Volltextsuche. Die ermöglicht die Suche in den Bereichen Überschrift, Beschreibung und ID (alles Felder aus der gemeinsamen Tabelle). Zusätzlich werden die Objekte nach der Objektsuche, entweder durch die Volltextsuche oder durch eine "Preissuche", aufgelistet und dazu wird auch wieder nur die gemeinsame Tabelle abgefragt.
Insgesamt habe ich mir wohl gedacht das es die Performance steigert und meinen Arbeitsaufwandt senkt.mfg
hulk
-
yo,
die datenbank würde in deinem falle eher schneller werden und der verwaltungsaufwand geringer, wenn du alles in ein tabelle packst. ob da nun einige spalten sind, die nicht von jedem objekt benutzt weden, hat kaum einfluss. eine tabelle sieht auch so schön kompakt aus und ist schnukelig, auch wenn das nicht gerade rationale argumente sind. ;-)
Ilja
-
-
-
-
-
-
-
-
-
-