3 Tabellen davon 2 Tabellen in der Haupttabelle übernehmen

[mickyturbo]

Abend,

weiss nicht ob ich damit richtig bin hier:

Tabelle_Gesamtübersicht

team freie_mb benutzte_mb
team A | 500 mb speicher verfügbar | benutze mb speicher*
team B | 500 mb speicher verfügbar | benutze mb speicher**
team C | 500 mb speicher verfügbar | benutze mb speicher***

*Tabelle Team A
benutzt_mb_a
team_a
Team A | 50
Team A | 50
Team A | 50

**Tabelle Team B
benutzt_mb_b
team_b
Team B | 10
Team B| 10

***Tabelle Team C
benutzt_mb_c
team_c
Team c | 100

es sollen die genutzen mb der einzelnen Tabellen summiert werden dann in Tabelle Gesamtübersicht bei benutzte mb speicher eingetragen werden

allerdings frage ich mich wie hab folgendes zusammengesetellt.

SELECT tg.team, tg.freie_mb, SUM(tg.benutzt_mb_c)
FROM Tabelle_Gesamtübersicht tg
full JOIN benutzt_mb_a t_a ON t_a.team_a = tg.team
full JOIN benutzt_mb_b t_a ON t_b.team_b = tg.team
full JOIN benutzt_mb_b t_c ON t_c.team_c = tg.team
GROUP BY tg.team

aktuelle ausgabe
team freie_mb benutzte_mb
team A | 500 mb speicher verfügbar | null
team B | 500 mb speicher verfügbar | null
team C | 500 mb speicher verfügbar | 20 mb (team_c)


wie bekomme ich die Ausgabe so hin?


team freie_mb benutzte_mb
team A | 500 mb speicher verfügbar | 150 mb (team_a )
team B | 500 mb speicher verfügbar | 20 mb (team_b )
team C | 500 mb speicher verfügbar | 20 mb (team_c)

(hab es nur so hinbekommen das er mir mehrere benutzte_mb ausgibt quasi für jedes team a /b/c ne neue spalte erzeugt) ausgabe sah folgendermaßen aus:

team freie_mb benutzte_mb | benutzte_mb | benutzte_mb
team A | 500 mb speicher verfügbar | 150 mb (team_a ) | NULL | NULL
team B | 500 mb speicher verfügbar | NULL | 20 mb (team_b )| NULL
team C | 500 mb speicher verfügbar | NULL | NULL | 20 mb (team_c)


Danke im voraus

 

[akretschmer]

Du suchst keinen JOIN sondern UNION, davon abgesehen ist Deine Tabellenstruktur Murks. Kommt ein neues Team dazu, muß Du:

• neue Tabelle anlegen
• vorhandene Programme und Abfragen ändern

Das skaliert also nicht und ist daher Müll. Du benötigst nur eine benutzt_mb - Tabelle, nicht eine je Team.

 

[mickyturbo]

wie sollten die Tabellen den aufgeteilt sein,

also es gibt Team was immer wieder mb nutzen kann also geht kein pkey auf team_name.
Auf was sollt ich dann den pkey setzten ?
auf ID z.B. ?

ich erzeuge immer so viele Tabellen da ich gedacht habe, so ne art Normalisierte DB zu erzeugen

ich versuche es mal und gebe feedback
thank you

 

[akretschmer]

also es gibt Team was immer wieder mb nutzen kann also geht kein pkey auf team_name.

Das hast Du jetzt auch nicht ;-)

Ja, eine automatisch generierte ID böte sich an, SERIAL. Eine Spalte mit einem FK zum Team, und eine mit den verbrauchten MB oder whatever das da sein soll. Und schon hast Du ALLES in einer Tabelle und kannst das schön aggregieren & auswerten. Falls Du jetzt Angst hast, die Tabelle könnte zu groß werden: einige 10 oder 100 Millionen Rows per Table ist kein Problem mit PG, Kunden haben teilweise einige Milliarden Rows per Table. Solltest Du da signifikant drüber kommen gibt es immer noch table-partitioning, besonders gut&elegant mit PG 10 machbar (und in der kommenden 11 nochmals um vieles besser).

 

[mickyturbo]

Hi, hat fast alles soweit geklappt nur beim Anlegen von mehreren firmen geht das nicht, da die Firma ja UNIQUE ist. Wenn man mehrere Ansprechpartner von der selben Firma anlegen möchte geht diese nur an wenn sie unterschiedlich sind zB. Sky , sky2 oder bei der Firma:sparkasse, sparkasse2

also hier mal mein Problem:
\d+ abo


firma_contact | character varying | not null | extended | |
user | character varying | | extended | |
login | character varying | | extended | |
address | character varying | | extended | |
comment | character varying | | extended | |
begin_date | date | | plain | |
end_date | date | | plain | |
duration | integer | | plain | |
serial_id | integer | not null Vorgabewert nextval('abo_serial_id_seq'::regclass) | plain | |
Indexe:

"firma_contract_pkey" PRIMARY KEY, btree (serial_id)

\d+ contact_data


contact_name | character varying | not null | extended | |
firma | character varying | not null | extended | |
payment method | character varying | | extended | |
telefon_nr | character varying | | extended | |
email | character varying | | extended | |
name | character varying | | extended | |
serial_id_cd | integer | not null Vorgabewert nextval('contact_data_serial_id_cd_seq'::regclass) | plain | |

Indexe:
"contact_data_pkey" PRIMARY KEY, btree (contact_name, serial_id_cd)
"contact_data_contact_name_key" UNIQUE CONSTRAINT, btree (contact_name)
"contact_data_firma_key" UNIQUE CONSTRAINT, bare (firma)

Fremdschlüsselverweise von:

TABLE "price" CONSTRAINT "price_contact_name_pr_fkey" FOREIGN KEY (contact_name_pr) REFERENCES contact_data(contact_name)


\d+ price


-----+--------------

month | integer | | plain | |
price_x_month | real | | plain | |
yeah | integer | | plain | |
price_x_yeah | real | | plain | |
contact_name_pr | character varying | not null | extended | |


Indexe:

"price_pkey" PRIMARY KEY, btree (contact_name_pr)

Fremdschlüssel-Constraints:

"price_contact_name_pr_fkey" FOREIGN KEY (contact_name_pr) REFERENCES contact_data(contact_name)



Sollten es kein sinn ergeben einfach bescheid geben lösche alles und erstelle neu, ist zwar ne sinnlose Tabelle aber ich brauche das sowieso für die nächste Klausur.

Danke nochmal

 

[akretschmer]

ich weiß ja nicht genau, was Du erreichen willst, aber:

• erste Tabelle, wozu dient duration?
• begin und end - date würde ich eher mittels daterange abbilden, kommt drauf an, wozu das noch so dienen soll
• contact_data, wozu den PK über contact_name, serial_id_cd?
• Tabelle price mit yeah - Feldern bleibt mir rätselhaft, auch der PK

 

[mickyturbo]

also das soll meine ganzen verträgt abbilden und dazu gehörigen Kontakt daten der Mitarbeiter z.b sky , fitness , Sparkasse usw.

duration ist eine hilfsspalte.
z.B. fitness 24 monate vertrag dann trag ich ein 15.02.18 bis 15.02.18 und duration wäre 24 Monate.
da kann ich mittels select z.B mir anzeigen lassen welcher vertrag welcher Ansprechpartner contact daten , sowie vertragslaufzeit.

contact_data PK contact_name da ich dachte jeder Mitarbeiter hat seine eigene eMail Adresse und die ist ja individuell und gibt es nur einmal.

Price hab ich nur so gemacht mit
sky price_x_moth 50 euro
sky price_x_year 600

damit ich das mittels select mit anzeigen kann welche vertrage wie lange laufen und was sie kosten.

Wie fängt man an mit so einer DB glaub nämlich das ich nicht weiss wie man sich vorher richtig Gedanken macht um sie dann umzusetzen in postgresql......
beginnt man mit Datenbank relation ?

 

[akretschmer]

z.B. fitness 24 monate vertrag dann trag ich ein 15.02.18 bis 15.02.18 und duration wäre 24 Monate.

Du speicherst also Start, Ende und die Differenz. Was passiert, wenn sich eine der 3 Größen ändert oder falsch eingetragen wird, wie in Deinem Beispiel? Dein End-datum - Start-Datum ergibt 0 als Duration, gespeichert sind aber 24 Monate. Welcher der Werte ist nun falsch, welchen hast Du zu korrigieren? Merke: alles, was berechenbar ist, speichert man nicht extra. Start und Ende, Start und Duration, Ende und Duration. NIEMALS NIE alle 3.

Preis-Tabelle: speichere doch die Monate. Die Verträge sind bestimmt immer ein ganzes Vielfache davon.

Und ja: man fängt damit an, sich zu überlegen, wie was zusammengehört. Das ist 3 Sätzen vollständig zu beschreiben fällt mir zumindest aber schwer. Aber da gibt es massig Literatur, google mal nach Normalisierung (in Zusammenhang mit Datenbanken)

 

[mickyturbo]

oh ja dann lösche ich eins ich denke am meisten sinn macht Start und duration

ja ich lasse bei Price nur Monate stehen dann kann ich das mittels select aufs Jahr aufsummieren.

 

[mickyturbo]

kleine frage, versuche in meiner Micky_db eine neue Tabelle zu erstellen
eBay

beim öffnen (view data -All rows)
der Tabelle kommt folgende Fehlermeldung :

ERROR: FEHLER: Relation „public.ebay“ existiert nicht LINE 1:
SELECT * FROM public.ebay
-------------------- ^
SQL state: 42P01 Character: 15



manchmal verstehe ich nicht wie es sein kann das immer neue Fehler bei mir auftauchen, ich glaub ich bin das Problem :-(
mach ich diese Tabelle in einer anderen DB rein klappt es wunderbar

 

[akretschmer]

Ja. Kann einige Ursachen haben:

• Tabelle nicht angelegt
• Tabelle in einem anderen Schema, welches nicht im search_path ist, angelegt
• Tabelle in einer anderen DB angelegt
• Fipptehler
• Tabelle mit gRoßBuChStAbEn / KlEiNbUcHsTaBeN gemisch angelegt (passiert gern bei PGAdmin)

um mal einige zu nennen.

 

[mickyturbo]

micky_db=# \dt

Liste der Relationen

Schema | Name | Typ | Eigentümer

--------+------------------------+---------+------------

public | contact_data | Tabelle | postgres
public | ebay_sicherheitsfragen | Tabelle | postgres
(2 Zeilen)

wenn ich jetzt allerdings in pgadmin mir die Tabellen von micky_db anschaue sehe ich
folgende Tabellen:

contact_data
ebay

 

[akretschmer]

Ich nutze kein PGAdmin, sorry. Aber im Zweifelsfalle ist das, was psql macht und sagt, korrekt.

 

[mickyturbo]

glaube der hat jetzt die Db upgedatet

da jetzt beides aktuell ist.

das heisst du machst alles über terminal psql ?

 

[mickyturbo]

sorry alex, lag wohl an der langsamen Verbindung bin nämlich per VPN verbunden und jetzt geht alles..


Danke und sorry nochmal.... hätte mich etwas gedulden müssen.