Probleme mit NULL Wert

[greifer]

Hallo Leute

Ich habe gerade festgestellt das ich ein Problem mit meiner MSSQL Datenbank habe. Viele Werte in einer Sprachtabelle sind mit NULL besetzt. Zum besseren Verständnis hänge ich ein Bild dran. Richtig ist es leider nur wie beim Beispiel "macaw/new navy".

Leider habe ich keine Ahnung von der Materie und hoffe auf eine gute Idee wie ich das Problem am besten angehen kann.

jede Anfangs ID (71464) braucht die Felder 1,2,3,6 mit immer den gleichen Wert wie bei 1

 

[akretschmer]

Hallo Leute

Ich habe gerade festgestellt das ich ein Problem mit meiner MSSQL Datenbank habe. Viele Werte in einer Sprachtabelle sind mit NULL besetzt. Zum besseren Verständnis hänge ich ein Bild dran. Richtig ist es leider nur wie beim Beispiel "macaw/new navy".

Schönes Bild.

Leider habe ich keine Ahnung von der Materie und hoffe auf eine gute Idee wie ich das Problem am besten angehen kann.

Bis jetzt kennen wir Dein Problem nicht.

jede Anfangs ID (71464) braucht die Felder 1,2,3,6 mit immer den gleichen Wert wie bei 1

Ahhh: Dein Problem ist fehlende Normalisierung. Die Rows mit ksprache in (2,3,6) sind also überflüssig, oder?

Was ist jetzt Dein Problem, ein 'delete from bla where ksprache in (2,3,6)' ?

Andreas

 

[greifer]

Hey Andreas vielen Dank erstmal für deine Nachricht.

Nein überflüssig ist nichts. In den NULL Zellen müßten Daten stehen. Immer wenn eine ID (kEigenschaftwert) und eine Nummer 1,2,3,6 (kSprache) vorhanden sind muß auch cName gefüllt werden.

kEigenschaftwert - kSprache - cName
71464 - 1 - macaw/new navy
71464 - 2 - macaw/new navy
71464 - 3 - macaw/new navy
71464 - 6 - macaw/new navy
<- ist Richtig

71465 - 1 - white/black
71465 - 2 - white/black
71465 - 3 - white/black
<- müßte so aussehen

 

[akretschmer]

Hey Andreas vielen Dank erstmal für deine Nachricht.

Nein überflüssig ist nichts. In den NULL Zellen müßten Daten stehen. Immer wenn eine ID (kEigenschaftwert) und eine Nummer 1,2,3,6 (kSprache) vorhanden sind muß auch cName gefüllt werden.

Wenn bei 2,3,6 das selbe wie bei 1 steht ist der Datensatz überflüssig. Das ist so, als wenn Du für jeden Menschen, der auf der Welt lebt, einen extra Datensatz hast mit der Spalte 'gattung' und dem Inhalt 'Mensch'. Bei 6 Milliarden Menschen hast dann 5999999999 unnütze Datensätze.

Aber wenn Du das wirklich willst:

test=# select * from greifer ;
 keigenschaft | ksprache |     cname
--------------+----------+----------------
            1 |        1 | bla/fasel/blub
            2 |        1 | foo/bar/blubb
(2 rows)

Time: 0,148 ms
test=*# insert into greifer select g.keigenschaft, foo.x, NULL from greifer g cross join (select 2 as x union select 3 union select 6 ) foo;
INSERT 0 6
Time: 0,343 ms
test=*# update greifer set cname = x.cname from (select keigenschaft, cname from greifer where ksprache = 1) x where greifer.keigenschaft=x.keigenschaft;
UPDATE 8
Time: 0,339 ms
test=*# select * from greifer order by 1,2;
 keigenschaft | ksprache |     cname
--------------+----------+----------------
            1 |        1 | bla/fasel/blub
            1 |        2 | bla/fasel/blub
            1 |        3 | bla/fasel/blub
            1 |        6 | bla/fasel/blub
            2 |        1 | foo/bar/blubb
            2 |        2 | foo/bar/blubb
            2 |        3 | foo/bar/blubb
            2 |        6 | foo/bar/blubb
(8 rows)

Andreas, legt sein Geld jetzt in Festplatten an ;-)

 

[akretschmer]

Andreas, legt sein Geld jetzt in Festplatten an ;-)

Du könntest auch eine VIEW definieren:

test=*# select * from greifer ;
 keigenschaft | ksprache |     cname
--------------+----------+----------------
            1 |        1 | bla/fasel/blub
            2 |        1 | foo/bar/blubb
(2 rows)

Time: 0,239 ms
test=*# create view view_greifer as select * from greifer union select g.keigenschaft, foo.x, g.cname from greifer g cross join (select 2 as x union select 3 union select 6) foo order by 1,2;
CREATE VIEW
Time: 105,963 ms
test=*# select * from view_greifer ;
 keigenschaft | ksprache |     cname
--------------+----------+----------------
            1 |        1 | bla/fasel/blub
            1 |        2 | bla/fasel/blub
            1 |        3 | bla/fasel/blub
            1 |        6 | bla/fasel/blub
            2 |        1 | foo/bar/blubb
            2 |        2 | foo/bar/blubb
            2 |        3 | foo/bar/blubb
            2 |        6 | foo/bar/blubb
(8 rows)

Genauso redundant, aber platzsparender ;-)

Andreas

 

[greifer]

Das Problem ist das die Datenbank zur einem System gehört was es leider so vorgibt und durch eine neue Sprache nun Werte nicht vorhanden sind. Da sich die Werte in der Tabelle jedoch nicht unterscheiden muß ich die Daten leider so angeben. Ich werde es auf dem Testsystem zuhause mal ausprobieren. Ich melde mich obs hinhaut

 

[akretschmer]

Das Problem ist das die Datenbank zur einem System gehört was es leider so vorgibt und durch eine neue Sprache nun Werte nicht vorhanden sind. Da sich die Werte in der Tabelle jedoch nicht unterscheiden muß ich die Daten leider so angeben. Ich werde es auf dem Testsystem zuhause mal ausprobieren. Ich melde mich obs hinhaut

Nun ja ;-)

Ich hab ja ein UPDATE-Befehl gezeigt. Das evtl. noch im WHERE erweitern um zu prüfen, daß a) wirklich nur bisherige NULL-Werte angefaßt werden und b) das auf Deine 2,3 und 6 begrenzen.

 

[ukulele]

Eigentlich sollte man ja erstmal den Fehler suchen warum eine Spalte, in der Informationen stehen müssen, nicht auch mit solchen befüllt wird. Das liegt hier aber wohl an der Anwendung, nicht an der Datenbank. In der DB kann man nur nach Gemeinsamkeiten der unvollständigen Daten suchen oder einen Fix testen, wenn man tatsächlich die Information aus anderen Daten zusammen setzen kann (was dann allerdings tatsächlich schlecht normalisiert wäre).

Des weiteren könntest du deine Test-Anwendung ärgern in dem du die, bevor du sie mit Daten fütterst, die Spalte auf NOT NULL setzt. Vermutlich knallts dann an irgend einer Stelle.