nicht angemeldet
Abfrage o./u. Design-Problem: "Simulation" Nested Tables
MudGuardHallo
Leider weiss ich beim besten Willen nicht, wie ich folgendes Problem lösen soll:
(als Beispiel)
Abbildung von Produkten in einer Datenbank. Produkt hat einen Titel, Beschreibung und Preis. Soweit alle einfach.
Nun soll jedes Produkt in beliebig vielen Sprachen und mit beliebig vielen Währungen (=andere Preise) verfügbar sein. Mit Nested Tables wäre das auch einfach zu realisieren.
Wie aber mache ich das in MySQL, dass ich mit einer einizigen Abfrage den ganzen Record auf einmal zurückbekomme? So Quasi, wie simuliere ich die Nested Tables?
Die Möglichkeit vom Speichern eines Serialisiertem Arrays in ein Datenfeld habe ich mir schon durch den Kopf gehen lassen und wieder verworfen, da ich auch nur einzelne Sprachen (aber auch alle auf einmal) Abfragen möchte (viel zu viele Daten).
Das Design habe ich mir mal so zurechtgelegt:
Produkt
- ID, PRIMARY KEY
- ... (z.B. Hersteller)
Produktdetail
- PrduktFID
- SpracheID
- Titel
- Beschreibung
PrimaryKey(PrduktFID, SpracheID)
Prduktpreis
- ProduktFID
- WaehrungID
- Preis
PrimaryKey(ProduktFID, WaehrungID)
Wie mache ich nun ein Abfrage aller Produkte mit allen Produktedetails und -Preisen, so dass ich pro Produkt nur einen Record habe?
Oder geht das gar nicht und ich muss pro Produkt 3 Abfragen starten?
Wäre echt nett wenn mir jemand weiterhelfen könnte. Irgendwie ist das doch ein Grundsätzliches Problem...
Dankeschön!
Gruss
-
Hi,
Wie aber mache ich das in MySQL, dass ich mit einer einizigen Abfrage den ganzen Record auf einmal zurückbekomme? So Quasi, wie simuliere ich die Nested Tables?
LOLs und so, ja Datenserverabfragen geben tendenziell nur Matrices zurueck. Eventuell kannst Du MySQL zu einer XML-Ausgabe bewegen?
Die Möglichkeit vom Speichern eines Serialisiertem Arrays in ein Datenfeld habe ich mir schon durch den Kopf gehen lassen und wieder verworfen, da ich auch nur einzelne Sprachen (aber auch alle auf einmal) Abfragen möchte (viel zu viele Daten).
Richtig, sowas macht man nicht.
Wie mache ich nun ein Abfrage aller Produkte mit allen Produktedetails und -Preisen, so dass ich pro Produkt nur einen Record habe?
Ich weiss jetzt nicht ganz genau was Du vorhast, beschaeftige Dich aber mal mit JOINen.
Oder geht das gar nicht und ich muss pro Produkt 3 Abfragen starten?
Wenn Du alle "Nachschlagetabellen" benoetigst, dann oft ja.
Wäre echt nett wenn mir jemand weiterhelfen könnte. Irgendwie ist das doch ein Grundsätzliches Problem...
Das stimmt.
Gruss,
Ludger -
yo,
Wie aber mache ich das in MySQL, dass ich mit einer einizigen Abfrage den ganzen Record auf einmal zurückbekomme? So Quasi, wie simuliere ich die Nested Tables?
mit mysql wirst du dafür wohl mindestens zwei tabellen brauchen und dementsprechend wird es auch schwierig werden, in einem datensatz eines produktes alle sprachen unterzubringen, da es sich ja um eine unbestimmte (beliebige) menge handelt. vielmehr wird deine ausgabe so sein, dass du pro sprache eines produktes einen datensatz bekommst oder aber pro produkt nur eine feste anzahl (z.b genau eine oder zwei, etc. )von sprachen.
das sollte aber nicht weiter tragisch sein, den a) kann ich mir nicht vorstellen, dass man immer alle sprachen auf einmal abfragen will, bzw. welchen sinn dahinter stecken sollte ausser für demonstrationszwecke. und b) werden die daten ja meistens über ein programm abgerufen, dass die daten dann in eine gewünschte form bringen kann.
was deine drei tabellen angeht, so kannst du dir die dritte sparen. der preis gehört ohnehin in die zweite tabelle und die währung kann man entweder auch dort mit reinnehmen, bzw. von der sprache als prozessdaten schließen lassen. oder aber du machst eine dritte länderspeziefische tabelle, wo die sprache und die währung drinne stehen. ich würde sie mir aber sparen.
Ilja
-
Hi,
» die währung kann man entweder auch dort mit reinnehmen, bzw. von der sprache als prozessdaten schließen lassen.
Hm. Sprache und Währung haben aber nichts miteinander zu tun.
Die Schweiz hat 4 Sprachen, aber nur eine Währung.
Französisch wird u.a. in Frankreich und der Schweiz gesprochen. Frankreich hat den Euro als Währung, die Schweiz den Franken.oder aber du machst eine dritte länderspeziefische tabelle, wo die sprache und die währung drinne stehen.
Länder und Sprachen haben aber nichts miteinander zu tun, s.o.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
Schreinerei Waechter
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
yo,
Hm. Sprache und Währung haben aber nichts miteinander zu tun.
Länder und Sprachen haben aber nichts miteinander zu tun, s.o.das stimmt so nicht. man hat sicherlich keine 1:1 zuordnung, so dass man eindeutige schlüße ziehen könnte. aber beziehungen gibt es dennoch oder hast du schon mal versucht, in einem restaurant in england mit rubel zu bezahlen und dem kellner das in chinesisch zu erklären, dass währung, sprachen und länder nichts miteinander zu tun haben ?
Ilja
-
Hi,
Hm. Sprache und Währung haben aber nichts miteinander zu tun.
Länder und Sprachen haben aber nichts miteinander zu tun, s.o.das stimmt so nicht. man hat sicherlich keine 1:1 zuordnung, so dass man eindeutige schlüße ziehen könnte. aber beziehungen gibt es dennoch oder hast du schon mal versucht, in einem restaurant in england mit rubel zu bezahlen
Wo hab ich behauptet, daß Länder und Währung keine Beziehung haben?
und dem kellner das in chinesisch zu erklären, dass währung, sprachen und länder nichts miteinander zu tun haben ?
Da ich kein Chinesisch kann, hab ich das noch nicht versucht.
Aber in vielen chinesischen Restaurants (egal ob in England oder sonstwo - also unabhängig vom Land, in dem sich das Restaurant befindet) verstehen die Kellner durchaus chinesisch (auch egal, welche Währung dann auf der Rechnung steht).cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
Schreinerei Waechter
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
yo,
Hm. Sprache und Währung haben aber nichts miteinander zu tun.
Länder und Sprachen haben aber nichts miteinander zu tun, s.o.Wo hab ich behauptet, daß Länder und Währung keine Beziehung haben?
mal davon abgesehen, dass deine beiden obigen aussagen meiner meinung nach nicht richtig sind, impliziert es wohl auch, dass länder und währung keine beziehung miteinander haben könnnen. den eine beziehung ist mehr als "haben nichts miteinander zu tun".
Ilja
-
Hi,
Hm. Sprache und Währung haben aber nichts miteinander zu tun.
Länder und Sprachen haben aber nichts miteinander zu tun, s.o.Wo hab ich behauptet, daß Länder und Währung keine Beziehung haben?
mal davon abgesehen, dass deine beiden obigen aussagen meiner meinung nach nicht richtig sind, impliziert es wohl auch, dass länder und währung keine beziehung miteinander haben könnnen. den eine beziehung ist mehr als "haben nichts miteinander zu tun".
Richtig, zwischen Laendern und Sprachen, sowie zwischen Sprache und Waehrung bestehen "n:m"-Beziehungen, also haben die miteinander was zu tun, sogar im umgangssprachlichen Gebrauch.
Ob diese Beziehung aber "nutzbar" ist, also in IT nachgegossen werden sollte, scheint ziemlich unklar (oder auch klar, je nach Sichtweise ;-).
Also habt Ihr (wie immer natuerlich) "irgendwie" beide recht.
Gruss,
Ludger
-
-
-
-
-
-
Hi lemats,
bei derart gelagerten Problemen habe ich mich in den vergangenen zwanzig Jahren häufig zu einer durchnormalisierten Lösung ähnlich Deinem Entwurf entschieden - und mich in jedem Fall früher oder später darüber schwarz geärgert. Diese Aufdröselung in drei oder mehr Tabellen, teilweise mit m:n-Relationen, führt zu komplexen, häufig mehrstufigen Abfragen, deren Performance bei wachsender Datenmenge überproportional zurückgeht und die Wahrung der referentiellen Integrität aufwendig macht. Im Nachhinein würde ich mich immer für eine Denormalisierung entschieden haben, häufig habe ich es mühsam am laufenden System tatsächlich vorgenommen - belohnt mit drastischer Performancesteigerung.
Solltest Du nicht tatsächlich _alle_ Sprachen - nach dem Etnologue zur Zeit 6.912 - erfassen müssen, so solltest Du die Vorteile einer Ein-Tabellen-Lösung mit sprach- und währungsspezifisch multiplen Spalten für Titel, Beschreibung, Preis etc. einmal abwägen...
hth Robert
-
Hi,
Solltest Du nicht tatsächlich _alle_ Sprachen - nach dem Etnologue zur Zeit 6.912 - erfassen müssen, so solltest Du die Vorteile einer Ein-Tabellen-Lösung mit sprach- und währungsspezifisch multiplen Spalten für Titel, Beschreibung, Preis etc. einmal abwägen...
OK, aber was machst Du, wenn das System erfolgreich wird? ;-)
Gruss,
Ludger-
Hi,
OK, aber was machst Du, wenn das System erfolgreich wird? ;-)
was meinst Du - daß Bedarf nach weitergefächerter Multilingualität besteht? Abwarten, Tee trinken... Ich würde meine Tabelle sicher sehr breit werden lassen, vielleicht sogar einige Dutzend Sprach-/Preisspalten breit; in einem strenger normalisierten Testsystem gelegentlich Gegenproben hinsichtlich der Performance machen (das System wird die dazu erforderlichen Mehraufwendungen ob seines Erfolges sicherlich problemlos vergüten können). Mehr Tee trinken.
hth Robert
-
Hi,
OK, aber was machst Du, wenn das System erfolgreich wird? ;-)
was meinst Du - daß Bedarf nach weitergefächerter Multilingualität besteht?
so speziell habe ich gar nicht gedacht. Nein, ich habe nur mich selbst zitiert, huestl, also, wenn ideologisch gepraegte Diskussionen zu Implementierungsfragen stattfinden, wenn es also bspw. darum geht wie genau man die Realitaet nachgiessen soll. Da kann man dann ja alles so oder so oder so sehen und auch die Gegner des korrekten Implementierens von realen Sachverhalten haben ja immer so Einwaende wie Performance und "nicht wirtschaftlich in der Umsetzung", ja und dann, dann ist das einzige was man noch fragen kann "OK, aber was machst Du, wenn das System erfolgreich wird?".
Gruss,
Ludger-
Hallo liebe Forumsgemeinde
Vielen Dank für eure Antworten.
Aufgrund der abschätzbaren Zahl der zu erwarteten Sprachen und Währungen werde ich auf ein denormalisierteres Design zurückgreiffen. Die Performanceeinbussen bei einer höheren Normalform sind einfach zu Gross.
Also abwarten und Tee trinken ;-)
Danke an alle
Habts gut
-
yo,
Aufgrund der abschätzbaren Zahl der zu erwarteten Sprachen und Währungen werde ich auf ein denormalisierteres Design zurückgreiffen. Die Performanceeinbussen bei einer höheren Normalform sind einfach zu Gross.
ich würde dir dazu raten, davon abstand zu nehmen. sicherlich ist denormalisierung in einigen fällen eine sinnvolle sache. aber zwei tabellen machen den kohl nicht wirklich fett und bringen auch vorteile. zum beispiel bei der suche nach bestimmten inhalten ist es sinnvoll einen index, bzw. eine volltextsuche zu erstellen. bei zwei tabellen musst du das nur über eine spalte tun, bei der denormalisierten form über soviele spalten, wie du sprachen hast. und das kann die wartung der datenbank doch stark beeinflussen. auch musst du jedesmal das tabellendesign ändern, wenn eine sprache hinzukommt und somit auch im größeren umfang deine programme, welche die daten auslesen und aufbereiten.
insofern ist es eine "gesunde" mischung aus normalisierung und denormalsierung, die ein gutes daten-desgin ausmachen. man sollte beides im auge haben.
Ilja
-
Hi,
insofern ist es eine "gesunde" mischung aus normalisierung und denormalsierung, die ein gutes daten-desgin ausmachen. man sollte beides im auge haben.
das ist schon an und fuer sich richtig, dennoch mal die Frage: Was spricht eigentlich wirklich dagegen alles richtig zu designen? (Performance und groesserer Umsetzungsaufwand lasse ich kaum gelten in "grossen Systemen", sowas bearbeitet man mit ein wenig Hardware oder mit Manpower ;-)
(Und das Problem ist auch das, dass wenn minderwertiges Datendesign als relativ natuerlich empfunden wird, dass dann immer wieder Diskussionen entstehen, ob man es nun "diesmal" richtig machen soll. Der Schlendrian zieht ein. "Lowperformernde Kommunikationsspezialisten" und "soziale Kompetenztraeger" werden dann auf einmal wichtiger als die Traeger der "richtigen" Expertenmeinungen. Schlecht skalierbare, kaum weiterentwicklungsfaehige und wartungsunfreundliche Systeme koennten die Folge sein; mit einem entsprechend grossen "kompetenten Betreuerstab" natuerlich.)
Gruss,
Ludger-
yo,
das ist schon an und fuer sich richtig, dennoch mal die Frage: Was spricht eigentlich wirklich dagegen alles richtig zu designen?
die praxis und das menschen unterschiedlich probleme lösen. nicht immer hand man freie hand, sondern hat meistens bestimmte vorgaben, an die man nicht rütteln kann. und dann muss man sehen, dass es nicht nur in der theorie, sondern auch in der praxis läuft und zwar mit den fähigkeiten und material, die einem zur verfügung stehen.
Ilja
-
Hi,
das ist schon an und fuer sich richtig, dennoch mal die Frage: Was spricht eigentlich wirklich dagegen alles richtig zu designen?
die praxis und das menschen unterschiedlich probleme lösen.
das genau ist das Problem, manche halten das Falsche fuer das Richtige. M.E. sollte man da ganz strikt diesen Meinungen rechtzeitig etwas entgegenstellen. Es ist eben "in der IT" nicht so, dass alle irgendwie recht haben.
Hast Du schon mal voellig verhunzte Systeme gesehen?
Gruss,
Ludger
-
-
-
-
-
-
-
-
yo,
führt zu komplexen, häufig mehrstufigen Abfragen, deren Performance bei wachsender Datenmenge überproportional zurückgeht
dieser aussage stimme ich zu.
und die Wahrung der referentiellen Integrität aufwendig macht.
diese aussage würde ich als falsch bewerten, das gegenteil sollte der fall sein.
Ilja
-
Yo!
führt zu komplexen, häufig mehrstufigen Abfragen, deren Performance bei wachsender Datenmenge überproportional zurückgeht
dieser aussage stimme ich zu.
und die Wahrung der referentiellen Integrität aufwendig macht.
diese aussage würde ich als falsch bewerten, das gegenteil sollte der fall sein.
eine Datenbasis ohne Unterstuetzung referentieller Integritaet kann verglichen mit einer die RI Unterstuetzende i.p. Datenzugriff aufwaendiger sein?
Gruss,
Ludger
-
-
-
Hi,
ich empfehle in diesem Zusammenhang eine annhähernd normalisierte Lösung mit Tabellen für die verschiedenen Entitäten und Tabellen um diese zusammenzuführen, dass sie geschäftsmäßig Sinn ergeben, allerdings kommt es darauf an, wie komplex dein System werden soll:
- Produkte, die nur für eine bestimmte Sprache/Land existieren sollen
- die Beschreibungsinhalte (mal Beschreibung, mal 2, mal keine) können sich je nach Sprache/Land unterscheiden
- ...
Evt. solltest du vielleicht auch an einer MySQL vorbeidenken und mit einem Xml-Schema und Xml-Dateien arbeiten. Im Gegensatz zu MySQL bringt das aber einigen Speicheroverhead (für die Tagnamen etc) mit sich sowie eine fehlende oder zu lasche Typisierung der Daten, wenn das Schema nicht ausgereift ist bzw. ganz ohne Schema gearbeitet wird. Aber einen Gedanken sollte es schon wert sein :-)
Ciao, Frank