Hallo Experten,
ich habe hier eine Tabelle folgenden Formats vorliegen:
+----+------+------------+---------------+
| Nr | Name | Kontaktart | Kontakt |
+----+------+------------+---------------+
| 1 |Hans | Mail | [email protected] |
| 2 |Hans | Telefon | 123456 |
| 3 |Peter | Mail | [email protected]|
| 4 |Peter | Telefon | 543210 |
usw.
Mit welcher Abfrage bekomme ich ein Ergebnis folgenden Formats:
+------+----------------+---------------+
| Name | Mail | Telefon |
+------+----------------+---------------+
|Hans | [email protected] | 123456 |
|Peter | [email protected] | 543210 |
usw.
Für einen kleinen Tipp wäre ich sehr dankbar.
Gruß -queiss-
Hallo,
> +----+------+------------+---------------+
> | Nr | Name | Kontaktart | Kontakt |
> +----+------+------------+---------------+
> | 1 |Hans | Mail | [email protected] |
> | 2 |Hans | Telefon | 123456 |
> | 3 |Peter | Mail | [email protected]|
> | 4 |Peter | Telefon | 543210 |
So eine Tabelle ist eine schlechte Idee. Besser wäre es, das ganze auf zwei Tabellen aufzuteilen:
Tabelle name:
+----+------+
| Nr | Name |
+----+------+
| 1 |Hans |
| 2 |Peter |
Tabelle Kontakt:
+----+------------+---------+
| Nr | Kontaktart | Kontakt |
+----+------------+---------+
| 1 | Telefon | 123456 |
| 1 | Mail | hans@...|
| 2 | Telefon | 543210 |
Dann kannst du auch mehrere Leute mit gleichem Namen speichern, und hast keine Informationen doppelt in der Datenbank.
Abfragen kannst du es dann als
SELECT name.Name, Kontakt.Kontakt AS Mail
WHERE name.Nr = Kontakt.Nr AND Kontakt.Kontaktart = "Mail";
Grüße,
Moritz
Hi!
> +----+------+------------+---------------+
> | Nr | Name | Kontaktart | Kontakt |
> +----+------+------------+---------------+
> | 1 |Hans | Mail | [email protected] |
> | 2 |Hans | Telefon | 123456 |
> | 3 |Peter | Mail | [email protected]|
> | 4 |Peter | Telefon | 543210 |
So eine Tabelle ist eine schlechte Idee. Besser wäre es, das
ganze auf zwei Tabellen aufzuteilen:
Wieso? Name ist der Foreign-Key zur Master-Tabelle, in der er der Primary Key ist - was wäre an dieser Idee schlecht? (Außer das Namen öfters vorkommen können, aber warum muß ich immer eine künstliche ID als Schlüssel haben?
> SELECT name.Name, Kontakt.Kontakt AS Mail
> WHERE name.Nr = Kontakt.Nr AND Kontakt.Kontaktart = "Mail";
Und so bekommst Du nur einen einzeiligen Kontakt raus …
Mein Tip mit der Ursprungstabelle unter Oracle wäre:
select a.name,a.mail,b.telefon
from (select name,kontakt from tabelle where kontaktart='Mail') a
,select name,kontakt from tabelle where kontaktart='Telefon') b
where a.name=b.name
- ohne Gewährleistung auf vollständige Richtigkeit, da nicht ausprobiert, aber ähnliches Problem so gelöst (@Moritz: dort natürlich mit ID’s
Grüße,
Tomh
Hallo,
Wieso? Name ist der Foreign-Key zur Master-Tabelle, in der er
der Primary Key ist - was wäre an dieser Idee schlecht? (Außer
das Namen öfters vorkommen können, aber warum muß ich immer
eine künstliche ID als Schlüssel haben?
Und ist die Möglichkeit eines doppelten Namens keinen Gedanken wert? Und was machst du, wenn jemand einen Namen ändert? Wenn du IDs vergeben hast, musst du nur eine Tabelle ändern - bei Namen musst du in allen Tabellen den Namen ändern.
Dass das unangenehm sein kann, sieht man am Beispiel von wer-weiss-was, wo man bis vor kurzem seine „Sternchen“ verloren hat, wenn man seine E-Mail-Adresse geändert hat. Und „Meine Artikel“ wohl auch.
Für mich sind solche Geschichten Grund genug, jede Form von Redundanz in Datenbanken zu vermeiden.
Grüße,
Moritz
Hi!
Und ist die Möglichkeit eines doppelten Namens keinen Gedanken
wert?
Ich zitiere: … was wäre an dieser Idee schlecht? (Außer
das Namen öfters vorkommen können …
Mir geht’s hier nur darum, daß ich nicht in jeder Micky-Mouse-Tabelle extra eine eigene ID brauche - sofern sich der Unique-Key nicht ändern kann/darf/soll - und so zum Primary Key _mutiert_ - es wird mMn zu oft an das Unmögliche gedacht, daß eventuell eintreten könnte, aber ganz einfach (vor allem in Kleinstapplikationen) nie eintreten wird …
Grüße,
Tomh
Hi!
Und ist die Möglichkeit eines doppelten Namens keinen Gedanken
wert?Mir geht’s hier nur darum, daß ich nicht in jeder
Micky-Mouse-Tabelle extra eine eigene ID brauche - sofern sich
der Unique-Key nicht ändern kann/darf/soll - und so zum
Primary Key _mutiert_ - es wird mMn zu oft an das Unmögliche
gedacht, daß eventuell eintreten könnte, aber ganz einfach
(vor allem in Kleinstapplikationen) nie eintreten wird …
- Ob „Kleinstapplikation“ oder nicht, ist eigentlich egal, aber das Design mit einem PK auf einem Namen ist einfach falsch. So designt, kann in der Applikation 2 Personen mit Namen „Meier“ schlicht und einfach nicht verwaltet werden, und das ist Käse…
Gruss
Hi!
aber das Design mit einem PK auf einem Namen ist einfach
falsch. So designt, kann in der Applikation 2 Personen mit
Namen „Meier“ schlicht und einfach nicht verwaltet werden, und
das ist Käse…
Klopf! Klopf! Klopf! Jemand zuhause, der auch endlich mal lesen kann??
Nochmals gaaaanz laangsaam zuum miitleeseen:
In einer kleinen Applikation (manchmal sogar größere) existiert eine Tabelle, in der ein alphanumerisches Feld vorkommt, das exakt die Bedingungen eines Primary Keys erfüllt: Unique und Not Null. Warum nicht mal ein Namensfeld? Warum sollte ich nun noch zusätzlich einen künstlichen Schlüssel dafür erstellen? Damit ich mir die Constraint-Regeln noch mehr aufblase und die Performance eine Spur verlangsame? Damit ich noch eine Sequence mehr verwalten muß? Damit die Checks in der Applikation und der Datenbank quantitativ noch mehr zunehmen?
Einem OCP sollte ich das Ganze eigentlich nicht hundert mal erklären müssen …
Grüße,
Tomh (ebenfalls OCP)
PS: Ein Feld „NAME“ ist halt selten eindeutig, aber es könnte ja in diesem speziellen Fall so sein, oder?
Mein Tip mit der Ursprungstabelle unter Oracle wäre:
select a.name,a.mail,b.telefon
from (select name,kontakt from tabelle where
kontaktart=‚Mail‘) a
,select name,kontakt from tabelle where
kontaktart=‚Telefon‘) b
where a.name=b.name
- ohne Gewährleistung auf vollständige Richtigkeit, da
nicht ausprobiert, aber ähnliches Problem so gelöst (@Moritz:
dort natürlich mit ID’s
Na ob das für einen Anfänger so einfach zu durchschauen ist?
Falls nicht:
Probiers mal damit die Tabelle einfach 2mal aufzunehmen statt den „From-subselects“, ansonsten den SQL aber gleich lassen, müsste ungefähr so aussehen:
SELECT k1.name, k1.kontakt, k2.kontakt
FROM tabelle k1, tabelle k2
WHERE k1.kontaktart = ‚Mail‘
AND k2.kontaktart = ‚Telefon‘
AND k2.NAME = k1.name
Klopf! Klopf! Klopf! Jemand zuhause, der auch endlich mal
lesen kann??Nochmals gaaaanz laangsaam zuum miitleeseen:
In einer kleinen Applikation (manchmal sogar größere)
existiert eine Tabelle, in der ein alphanumerisches Feld
vorkommt, das exakt die Bedingungen eines Primary Keys
erfüllt: Unique und Not Null. Warum nicht mal ein Namensfeld?
Warum sollte ich nun noch zusätzlich einen künstlichen
Schlüssel dafür erstellen? Damit ich mir die Constraint-Regeln
noch mehr aufblase und die Performance eine Spur verlangsame?
Damit ich noch eine Sequence mehr verwalten muß? Damit die
Checks in der Applikation und der Datenbank quantitativ noch
mehr zunehmen?Einem OCP sollte ich das Ganze eigentlich nicht hundert mal
erklären müssen …
- Nein, sicher nicht
. Tut mir leid, wenn ich dich auf die Palme gebracht habe .
Grüße,
Tomh (ebenfalls OCP)PS: Ein Feld „NAME“ ist halt selten eindeutig, aber es könnte
ja in diesem speziellen Fall so sein, oder?
- Ja, könnte es…Im Orignialpost von Daniel ist aber nirgends davon die Rede, dass der Name als PK herhalten könnte, so bin ich davon ausgegangen, das es eben nicht so ist