This is topic Kleine MySQL Frage in forum Produktions- & DJ-Technik, Hard- & Software at technoforum.de.


Um den Thread anzusehen, klicke auf diesen Link:
https://forum.technoforum.de/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=6;t=005303

Geschrieben von: nicogrubert (Usernummer # 1292) an :
 
Ich habe 3 Tabellen:

- Persontyp_A (12 spalten)
- Persontyp_B (5 spalten)
- Relation_1 (Spalten: rel_id, column1, column2, name_id)


In der Tabelle 'Relation_1' will ich in der spalte "name_id" die Id einer Person speichern.
Problem: Diese Id kann entweder aus der Tabelle 'Persontyp_A' oder 'Persontyp_B' stammen.
Das Problem ist: Woher weiss ich später beim SELECT Statement, in welcher Tabelle er suchen soll, wenn ich z.B. nach einem Datensatz mit der name_id = 5 suche?

Wie löse ich das ganze am besten? Brauche ich eine weitere Tabelle?


Danke im voraus.
 
Geschrieben von: darks (Usernummer # 739) an :
 
wieso gibt es denn ueberhaupt 2 personen typen ?!?

normalerweise gibt es eine tabelle mit den personaldaten und somit eine eindeutige id. zusatzinformationen speicherst du dann noch in ner extra tabelle ab.

hier also alles gemeinsame von typ_a und typ_b als personaltabelle (ich gehe jetzt einfach mal davon aus das person_a nur eine erweiterung von person_b ist). und eine zusatztabelle id_person, erweiterungen.
 
Geschrieben von: Inkubator (Usernummer # 3755) an :
 
schliesse mich darks mal an und bezweifle die notwendigkeit von 2 personentabellen. das kann jedoch applikatorische gründe haben und drum würd ich dir mal vorschlagen UNION's anzuschauen.

http://www.mysql.com/doc/en/UNION.html
 
Geschrieben von: Braindrain (Usernummer # 629) an :
 
wenn es keine gleichen name_id eintraege in Persontyp_A
und
Persontyp_B
gibt, kannst du subselects benutzen.
 
Geschrieben von: minimalniemand (Usernummer # 3401) an :
 
Subselects sind in der derzeitigen MySQL Version noch nicht zu 100% implementiert.


Ich könnte mir z.B. eine Personentabelle mit ner Spalte Personentyp vorstellen. Dann bist du für später gerüstet, wenn ein weiterer Personentyp hinzukommt (Bei deiner Lösung müsste man eine Tabelle hinzufügen)

Ansonsten find ich das Handling ziemlich russisch ... warum sollte man Fremdschlüssel zweier Tabellen in ein und die selbe Spalte einer dritten Tabelle schreiben?
Entweder es sind verschiedene Daten, dann verschiedene Spalten. Oder wenn nicht, dann gleiche Spalte und gleiche Tabelle!

Gib mal mehr Info. Also was soll bezweckt werden? was soll mit was in Beziehung gesetzt werden und warum etc.
Sonst ist es schwierig zu sagen, welche Daten wo hin gehören.

Gesetzt den Fall, du willst (musst) es so machen kannst du noch in die Tabelle Relation_1 noch eine weitere Spalte Relation_Typ einfügen, in der Du beim Speichern des Datensatzes einfügst aus welcher Tabelle er kommt.

Oder in der Relationstabelle 2 Spalten: nameA_id und nameB_id

Ansonsten gibts keine Möglichkeit, das über Abfragen zu machen - in der Spalte steht ja nur eine Zahl. afaik ist es nicht möglich im Nachhinein zu bestimmen aus welcher Tabelle der Wert ursprünglich kam. Wär auch zu krass...

@ Inkubator: Warum sollte er die Abfrageergebnisse kombinieren wollen??
edit: Es sei denn du willst es so machen:

SELECT NULL AS nameA_id, name_id AS nameB_id FROM Relation1 WHERE name_id in (SELECT ID FROM PersonentypA)
UNION
SELECT name_id AS nameA_id, NULL AS nameB_id FROM Relation1 WHERE name_id in (SELECT ID FROM PersonentypB)

Dann hättest Du in einem Resultset eine entsprechende Übersicht über die IDs der beiden Personentypen ... aber das bringt uns irgendwie nicht weiter ....

keine Ahnung ob das funzt, arbeite mit TSQL
 
Geschrieben von: Cymorris (Usernummer # 5951) an :
 
Ich hätte jetzt auch mal ne Theorie aufgestellt, soweit ich das zu verstehen glaube...

SELECT * FROM Persontyp_A, Persontyp_B, Relation_1 WHERE
Personentyp_A.name_id = Relation_1.name_id OR
Personentyp_B.name_id = Relation_1.name_id;

Für * kannst du dann alle Spalten angeben, die du haben willst... Geht das ?
 
Geschrieben von: harryp (Usernummer # 5896) an :
 
@Cymorris
Damit Deine Abfrage aufgelöst werden kann, wird erstmal ein kartesisches Produkt über alle 3 Tabellen erzeugt.
Er verbindet alle Zeilen der 3 Tabellen miteinander und fragt dann die Where-Bedingungen ab.
Da kommt dann nicht das richtige raus und zum anderen ist es grottenschlecht für die Laufzeit.

@nicogrubert
Mal abgesehen, ob Deine Anfrage sinnvoll ist,
würd ichs mit einem Union machen.
Das einzig blöde am Union ist, daß Du in der einen Tabelle 5 Spalten und in der anderen 12 Spalten hast.
Der Union braucht in beiden Abfragen die selbe an Anzahl und Struktur von Feldern.
Deshalb mußt Du dann in den Selects mit Platzhaltern arbeiten.
 
Geschrieben von: Inkubator (Usernummer # 3755) an :
 
@minimalniemand
naja, wenn ichs richtig verstanden habe, sollte das ergebnis seiner gewünschten abfrage 1 row zurückliefern (ansonsten ist die relation über die zwischentabelle fucked up). mit anderen worten er muss die abfrage so einschränken dass nur ein resultat hinten rausschaut. welche felder (des kombinierten ergebnisses) er dann benutzt um die zwischentabelle zu füllen ist doch ziemlich wurscht.

alternativ kann man ja auch einfach 2 abfragen machen und schauen was hinten rauskommt, also quasi eine UNION simulieren. da ich meine programme möglichst auf einfachheit optimiere bevorzuge ich eh diese version. eine abfrage nach der anderen, sequenziell, die benötigten daten im speicher und von hand aussortieren ==> mehr kontrolle und übersicht. aber hier wirds schon fast philosophisch...
 
Geschrieben von: Inkubator (Usernummer # 3755) an :
 
nocheinmal @minimalniemand
wenn daten nicht vom system bereitgestellt werden muss man sich sie halt selber beschaffen. um konkreter zu werden:

code:
  
SELECT feld1, feld2, "PT_A" as Source
FROM PersonenTyp_A
WHERE feld3=<wert>
AND feld4=<wert>

UNION

SELECT feld1, feld2, "PT_B" as Source
FROM PersonenTyp_B
WHERE feld3=<wert>
AND feld4=<wert>

so. das ergebnis gibt _rc_ rows zurück, es gilt zu entscheiden was zu tun ist

code:
  
switch _rc_
falls 0:
break; // nix zum tun
falls 1:
if <Source> == "PT_A"
// füge ein in relation, kommend von personen-tabelle a
addRelation(resultset, "PT_A");
else
// füge ein in relation, kommend von personen-tabelle b
addRelation(resultset, "PT_B");
break; // feddisch
default:
// arghhl, zuviel fleisch am knochen
hup("seeeehr laut");

kann man sicherlich noch eleganter machen, aber zur anschauung reichts.
 
Geschrieben von: nicogrubert (Usernummer # 1292) an :
 
danke für die antworten.

kurzen blackout gehabt. :-D natürlich wird's mit 2 tabellen gemacht.
 



(c) 1999/2ooo/y2k(+1/+2/+3+4+5+6+7+8+9+2010+2011+2012+2013+2014+2015+2016+2017+2018+2019+2020+2021+2022+2023+2024) technoforum.de | www.techno-forum.de
Das Forum für Techno | House | Minimal | Trance | Downbeats | DnB | Grime | Elektro | IDM | Elektronika | Schranz | MNML | Ambient | Gefrickel | Dub | 2Step | Breakcore | no Business Techno | Dubstep | Big Room Techno | Grime | Complextro | Mashups | mnml | Bootlegs | Chicago House | AI Music | Acid House | Detroit Techno | Chillstep | Arenastep | IDM | Glitch | Grime | Experimental | Noise | Fidgethouse | Ableton Live 12 | Melbourne Bounce | Minimal Trap | Sinee | sounds | EDM | Splice | Bandcamp Soundcloud | Download | Progressive Electro House |
Betreiberangaben & Impressum siehe readme.txt, geschenke an: chris mayr, anglerstr. 16, 80339 münchen / fon: o89 - 5oo 29 68-drei
E-Mail: webmaster ät diesedomain
similar sites: www.elektronisches-volk.de | Ex-Omenforum | techno.de | USB | united schranz board | technoboard.at | technobase | technobase.fm | technoguide | unitedsb.de | tekknoforum.de | toxic-family.de | restrealitaet restrealität | boiler room
Diese Seite benutzt Kuhkies und du erklärst dich damit bei Betreten und Benutzung dieser Seite damit einverstanden. Es werden keinerlei Auswertungen auf Basis ebendieser vorgenommen. Nur die Foren-Software setzt Kuhkies ausschließlich für die Speicherung von Nutzerdaten für den einfacheren Logon für registrierte Nutzer, es gibt keinerlei Kuhkies für Werbung und/oder Dritte. Wir geben niemals Daten an Dritte weiter und speichern lediglich die Daten, die du uns hier als Nutzer angegeben hast sowie deine IP-Adresse, d.h. wir sind vollkommen de es fau g o-genormt, nixdestotrotz ist das sowieso eine PRIVATE Seite und nix Gewerbliches.
unitedwestream - #stayathome - #WirBleibenZuhause - corona livestream - twitch - dj stream - #savegroovemag - #blackouttuesday


Powered by Infopop Corporation
UBB.classicTM 6.5.0