Mehrfache counts auf Tabellen

hhbr89

Aktiver Benutzer
Beiträge
34
Verzweifel irgendwie an einer, von mir leicht geglaubten Aufgabe.

Wir sollen die Anzahl von Büchern und Autoren aus zwei Tabllen herausfinden und das Ergebniss in jeweils einer Spalte ausgeben. Mein Denkansatz war:

select count(*) as "Anzahl Buecher", count(*) as "Anzahl Autoren" from buch, autor

Leider multipliziert er mir die zwei counts und gibt mir diese in den Spalten aus.
 
Werbung:
Verzweifel irgendwie an einer, von mir leicht geglaubten Aufgabe.

Wir sollen die Anzahl von Büchern und Autoren aus zwei Tabllen herausfinden und das Ergebniss in jeweils einer Spalte ausgeben. Mein Denkansatz war:

select count(*) as "Anzahl Buecher", count(*) as "Anzahl Autoren" from buch, autor

Leider multipliziert er mir die zwei counts und gibt mir diese in den Spalten aus.

Du machst einen Cross Join, daher.

Code:
test=*# select * from (select count(*) count_t1 from t1) bar, (select count(*) count_t2 from t2) foo;

Andreas
 
Ich hatte schon einmal mehrfache select Anweisungen, nur habe ich keine Aliase vergeben. Danke.

Wieviele verschiedene Bücher, Autoren und Schlagworte gibt es? Geben Sie
die Antwort als eine Tabelle (mit einer Zeile) mit den Spaltennamen ’Anz
Buecher’, ’Anz Autoren’, ’Anz Schlagworte’ aus.

Code:
select * from (select count(bid) as "Anzahl Buecher" from buch) Anzahl, (select count(aid) as "Anzahl Autoren" from autor) Autoren, (select count(sid) as "Anzahl Schlagworte" from sachverz) Schlagworte

Falls es noch jmd. über Google sucht, hier die Antwort :p
 
Will ja nicht ständig einen Thread aufmachen, daher stelle ich die Frage einfach hier.

Wie kann ich in einer Spalte nach Daten suchen, die zum Beispiel mit Datenbanken beginnen, ohne eine like Anweisung?

Mit select ist es ja ganz einfach...

Code:
select titel, verlag, ort, jahr from buch where titel like 'Datenbanken%'
 
Du könntest mit left(), right() und / oder substring() arbeiten und das dann mit = prüfen. LIKE ist aber schon recht bequem und ich denke Geschwindigkeitsmäßig wirst du nicht viel gewinnen.
 
Was hast du gegen LIKE?

Also ich habe gegen LIKE gar nichts, nur steht das in einer Aufgabenstellung... :/ Gibt aber denke ich nur 1-2 Punkte, daher lasse ich das einfach weg. Viel interessanter wäre, wie ich einen Datentyp in einer select-Anweisung ändere, bzw. ob das überhaupt möglich ist. Unser kluger Prof. hat als Datentyp für Jahr den char genommen, natürlich etwas unvorteilhaft...

Erstellen Sie eine Liste aller Bücher mit Erscheinungsjahr zwischen 1995
und 2010, welche sowohl mit den Schlagworten ’Datenbanken’ als auch
’Datenbanksystem’ beschrieben sind. Die Liste soll nach Erscheinungsjahr
und Namen des Autors sortiert sein, sie soll folgende Spalten enthalten:
Name des Autors, Titel, Verlag, Jahr, Anmerkung.


select name, titel, verlag, jahr, anmerkung from buch join ba on buch.bid = ba.bid join autor on ba.aid = autor.aid
where titel like '%Datenbanken%' and titel like '%Datenbanksystem%' and jahr between 1995 and 2010
order by jahr,name
 
Zuletzt bearbeitet:
Das geht grundsätzlich damit:
Code:
SELECT jahr::integer
FROM buch

Habe ich probiert, dann kommt aber:

FEHLER: Operator existiert nicht: character varying >= integer
LINE 2: ...ken%' and titel like '%Datenbanksystem%' and jahr between 19...
^
HINT: Kein Operator stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.

Muss ich das mit Cast vielleicht umwandeln?
 
Habe ich probiert, dann kommt aber:

FEHLER: Operator existiert nicht: character varying >= integer
LINE 2: ...ken%' and titel like '%Datenbanksystem%' and jahr between 19...
^
HINT: Kein Operator stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.

Muss ich das mit Cast vielleicht umwandeln?


works for me:

Code:
test=*# create table foo (jahr varchar);
CREATE TABLE
Time: 27,420 ms
test=*# insert into foo values ('2014');
INSERT 0 1
Time: 0,307 ms
test=*# select *, jahr::int + 10 from foo;
 jahr | ?column?
------+----------
 2014 |  2024
(1 row)
 
Habe ich probiert, dann kommt aber:

FEHLER: Operator existiert nicht: character varying >= integer
LINE 2: ...ken%' and titel like '%Datenbanksystem%' and jahr between 19...
^
HINT: Kein Operator stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.

Muss ich das mit Cast vielleicht umwandeln?


Ahh, jetzt sehe ich, was Du uns verheimlicht hast:

Code:
test=*# create table foo (jahr varchar);
CREATE TABLE
Time: 8,232 ms
test=*# insert into foo values ('2014');
INSERT 0 1
Time: 0,314 ms
test=*# select * from foo where jahr > 2012;
ERROR:  operator does not exist: character varying > integer
LINE 1: select * from foo where jahr > 2012;
  ^
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.
Time: 0,931 ms
test=*# select * from foo where jahr::int > 2012;
 jahr
------
 2014
(1 row)
 
Ohhh, mein Fehler. Wusste nicht das ich es in der where clause nutzen kann/muss.

select name, titel, verlag, jahr, anmerkung from buch join ba on buch.bid = ba.bid join autor on ba.aid = autor.aid
where titel like '%Datenbanken%' or titel like '%Datenbanksystem%' and jahr::integer between 1995 and 2010
order by jahr,name

Funzt wunderbar :)
 
select name, titel, verlag, jahr, anmerkung from buch join ba on buch.bid = ba.bid join autor on ba.aid = autor.aid
where titel like '%Datenbanken%' or titel like '%Datenbanksystem%' and jahr::integer between 1995 and 2010
order by jahr,name

Wäre vielleicht sinnvoll, das Jahr gleich als INT zu speichern. So kann es passieren, daß da mal ein Dödel '1. Quartal 2014' eingibt, schon 'funzt' Deine Abfrage nicht mehr. Ließe sich zwar dann auch umgehen, aber ich denke, ein INT wäre da sinnvoller und sicherer.
 
Werbung:
Wäre vielleicht sinnvoll, das Jahr gleich als INT zu speichern. So kann es passieren, daß da mal ein Dödel '1. Quartal 2014' eingibt, schon 'funzt' Deine Abfrage nicht mehr. Ließe sich zwar dann auch umgehen, aber ich denke, ein INT wäre da sinnvoller und sicherer.

Ja so würde ich es auf jeden Fall auch machen, allerdings wurde uns die DB von unserem Prof so vorgegeben. Keine Ahnung warum er dort ein char gewählt hat... vllt um uns zu nerven.
 
Zurück
Oben