Datenbank für AnforderungsManagement

[akretschmer]

Das ist wirklich nicht sehr professionell, nicht mal eine Warnung gibts.

Leider wird jetzt meine Tabelle UnterAnforderung nicht mehr erstellt. Das hier hab ich im Manual gefunden:


1005 (ER_CANT_CREATE_TABLE)
Tabelle kann nicht angelegt werden. Wenn die Fehlermeldung auf errno 150 verweist, schlug die Tabellenerzeugung fehl, weil ein Fremdschlüssel-Constraint nicht richtig gebildet wurde.

allerdings kann ich beim besten Willen keinen Fehler entdecken. Hier mal der Code aller Tabellen:

Deine KlassenID ist INT, in UnterAnforderungen versuchst Du mit `Klassifizierung` char(50) DEFAULT NULL das zu referenzieren, Völlig anderer Datentyp.

Andreas

 

[RedFerret]

Ah, du bist super. Hatte da mal was geändert. Ich hab da irgendwie noch keinen Blick für...


EDIT:
Aber da scheint noch was nicht zu stimmen, Fehler bleibt

 

[akretschmer]

Ah, du bist super. Hatte da mal was geändert. Ich hab da irgendwie noch keinen Blick für...


EDIT:
Aber da scheint noch was nicht zu stimmen, Fehler bleibt

Ah, du bist super. Hatte da mal was geändert. Ich hab da irgendwie noch keinen Blick für...


EDIT:
Aber da scheint noch was nicht zu stimmen, Fehler bleibt

Ja, Klasse versus Klassen. Du erstellst Tabelle Klassen, referrnezierst aber auf Klasse. Klasse!

Andreas

 

[RedFerret]

Du bist klasse!

 

[akretschmer]

Du bist klasse!

Danke ;-)

Andreas

 

[RedFerret]

Da bin ich wieder.

Neuer Tag, neue Fehlersuche...
Meine View soll mir die HauptAnforderungen und dazu die Anzahl der UnterAnforderungen pro HauptAnforderung ausgeben, gibt mir stattdessen aber nur die oberste HauptAnforderung und die Anzahl aller UnterAnforderungen aus. Das kann ich nicht verstehen, da ich ja in der where-Bedingung festlege, dass die Reihen addiert werden sollen, wo HauptAnforderungsID = AnforderungsID aus den jeweiligen Tabellen ist. Ich steh mal wieder auf dem Schlauch.

delimiter $$
 
CREATE
 
ALGORITHM=UNDEFINED DEFINER=`root`@`localhost`
SQL SECURITY DEFINER
 
VIEW `uanf_pro_hanf` AS select `hauptanforderungen`.`AnforderungsID`AS`anforderungsid`,
count(`unteranforderungen`.`HauptAnforderungsID`) AS `anzahl_uanf`
from (`hauptanforderungen` join `unteranforderungen`)
where (`unteranforderungen`.`HauptAnforderungsID` = `hauptanforderungen`.`AnforderungsID`)$$

EDIT:
Habs gefunden

"group by hauptanforderungen.anforderungsid" fehlt.

 

[RedFerret]

Heute Nacht Träume ich von Datenbanken. Bin auf die nächste unüberwindbare Hürde für mich gestoßen.
Versuche eine StoredProcedure zu schreiben die ein neues Produkt mit einer um 1 erhöhten ProduktID anlegt aber meine Syntax stimmt nicht.

delimiter $$ 
CREATE DEFINER=`root`@`localhost` PROCEDURE p_neues_projekt 
(in ProduktID int(11), in ProduktName char(50), in AuslieferungsTermin date)
AS
DECLARE VARIABLE mID INTEGER; 
DECLARE VARIABLE pID INTEGER; 
BEGIN 
SELECT MAX(ProduktID) + 1 FROM Produkte INTO :mID; 
INSERT INTO Produkte   
(ProduktID, ProduktName, AuslieferungsTermin)   
END| $$

Bei "INSERT INTO Produkte" muss ich vermutlich iwas mit mID hinschreiben. Hab mir den Code aus einem Beispielcode zusammengebastelt, hab noch nie ne StoredProcedure geschrieben...

 

[akretschmer]

Heute Nacht Träume ich von Datenbanken. Bin auf die nächste unüberwindbare Hürde für mich gestoßen.
Versuche eine StoredProcedure zu schreiben die ein neues Produkt mit einer um 1 erhöhten ProduktID anlegt aber meine Syntax stimmt nicht.

Hier stimmt nicht (nur) die Syntax nicht, sondern auch die Idee dahinter. MySQL hat AUTO_INCREMENT, PostgreSQL SERIAL. Das verwendet man, dazu gibt es dann auch Funktionen, um die letzte vergebene ID in der jeweils aktuellen Session zu ermitteln.

Andreas

 

[RedFerret]

Hab mal wieder einen Hänger.

Kurz und knapp:
Es sollen die Mitarbeiter angezeigt werden, die an einem Produkt mitarbeiten. Mit meiner Abfrage tauchen die Mitarbeiter aber mehrmals auf, wenn sie mehrere Anforderungen des Produkts zu erledigen haben. Das soll nicht sein. Wie könnte man das ändern?

create view Mitarbeiter_pro_Produkt as
 
select
produkte.produktID as ProduktID,
produkte.produktname as ProduktName,
Mitarbeiter.MitarbeiterID as MitarbeiterID,
Mitarbeiter.MitarbeiterNachName as MitarbeiterName
from
Mitarbeiter join Produkte join UnterAnforderungen
where
Mitarbeiter.MitarbeiterID = unteranforderungen.MitarbeiterID
 
order by Produkte.ProduktID;

Und was ist der Unterschied wenn man statt join einfach ein Komma benutzt?

 

[akretschmer]

Hab mal wieder einen Hänger.

Kurz und knapp:
Es sollen die Mitarbeiter angezeigt werden, die an einem Produkt mitarbeiten. Mit meiner Abfrage tauchen die Mitarbeiter aber mehrmals auf, wenn sie mehrere Anforderungen des Produkts zu erledigen haben. Das soll nicht sein. Wie könnte man das ändern?

Mit DISTINCT. Read more: http://www.1keydata.com/de/sql/sql-distinct.php

Und was ist der Unterschied wenn man statt join einfach ein Komma benutzt?

Du hast da einen Mix.

Sauber wäre etwas wie:

... from mitarbeiter left join unteranforderungen on (mitarbeiter.mitarbeiterid = unteranforderungen.mitarbeiterid) ...

Da sieht man dann z.B. daß es ein LEFT JOIN ist (von der linken Seite tauchen alle Rows auf, von der rechten nur die, wo die on(...) - Condition erfüllt ist.

Es gibt massig Doku dazu, kannst ja mal hier anfangen: http://aktuell.de.selfhtml.org/artikel/datenbanken/joins/

Andreas

 

[RedFerret]

Aber wenn ich DISTINCT benutze kommt jeder Mitarbeiter nur einmal insgesamt vor, das darf ja auch nicht sein, da er ja mehrmals vorkommen kann wenn er an mehreren Produkten mitarbeitet. Er darf halt pro Produkt nur einmal vorkommen.

 

[akretschmer]

Aber wenn ich DISTINCT benutze kommt jeder Mitarbeiter nur einmal insgesamt vor, das darf ja auch nicht sein, da er ja mehrmals vorkommen kann wenn er an mehreren Produkten mitarbeitet. Er darf halt pro Produkt nur einmal vorkommen.

Nun, dafür gibt es auch Lösungen: entweder mit einem Select erst mal die Produkte selektieren und das dann mit den Mitarbeitern joinen. Oder: zumindest PostgreSQL kennt ein DISTINCT ON(...), mit dem man das recht einfach machen kann. Du hast aber MySQL, oder? Da geht das wohl nicht, also erster Ansatz.

Andreas