Update aus Tabelle (MS -SQL Server)

[Steel]

Hi!

Ich hab da eigentlich kein wirkliches Problem. Ich bin auf der Suche nach einer verainfachung oder besser: ich haetts gern uebersichtlicher.

Ich habe 2 Tabellen. Die erste enthaelt ueber hundert Datenfelder, die allesamt eingegeben werden koennen. Bevor das passiert wird aber jeder neue Datensatz mit Planzahlen aus der zweiten Tabelle versehen. Das sind z.Zt.  knapp 20 Felder.

Gibt es eien Methode Tabelle eins (daten) mit den Daten von Tabelle zwei (plan) zu fuellen ohne jedes Feld einzeln aufzuzaehlen? Der Query is etwas lang und ich haette es gern kuerzer.

Zur Veranschaulichung:
Tabelle 'Daten'
datum / key
ort   / key
planA
feld1
planB
feld2

Tabelle 'Plan'
datum / key
ort   / key
planA
planB

Ich moechte nun planA - planN von Tag x und ort y in die 'Daten' tabelle einfuegen.

Haben tu ich:
UPDATE daten d, plan p
SET d.planA = p.planA, d.planB = p.planB
WHERE d.datum = p.datum and d.ort = p.ort and d.datum='05/12/2007' and d.ort='Hogwarts'

Aber mit nochmal n Feldern mehr wirds lustig und es soll wartbar sein.

Falls es also sowas gibt wie 'nimm alle Felder aus Tabelle 2 und kopier sie ueber die Felder in Tabelle 1 wo datum und ort (oder was auch immer noch key ist) entsprechend vorhanden sind', waer ich sehr dankbar.

Gruss,

[Steel]

Na gut.

Meine Idee:
Morgen werd ich versuchen mit Hilfe INFORMATION_SCHEMA.COLUMNS (hier sind die Strukturen der Datenbank gespeichert, also alle Tabellen mit Feldnamen, Typ, ...) das ganze dynamisch per ASP zu regeln. Scheint ne brauchbare Loesung zu sein, mir da die Feldnamen der Plantabelle rauszupicken, die ja mit den entsprechenden Feldnamen in der Datentabelle uebereinstimmen.

Ansonsten: immer her mit Loesungen, falls ihr welche habt.

[Sven Rautenberg]

Moin!

Meine Idee:
Morgen werd ich versuchen mit Hilfe INFORMATION_SCHEMA.COLUMNS (hier sind die Strukturen der Datenbank gespeichert, also alle Tabellen mit Feldnamen, Typ, ...) das ganze dynamisch per ASP zu regeln. Scheint ne brauchbare Loesung zu sein, mir da die Feldnamen der Plantabelle rauszupicken, die ja mit den entsprechenden Feldnamen in der Datentabelle uebereinstimmen.

Das klingt allerdings jetzt nicht wirklich überzeugend. Üblicherweise geht man bei einer Datenbank-Applikation ja davon aus, dass die Applikation ihr Datenmodell kennt, d.h. du mußt nicht erst die Datenbank fragen, welche Datenbanken, Tabellen und Spalten in ihr existieren, um dann genau diese abzufragen - es sei denn, du schreibst ein Datenbankadministrationstool.

Ausgehend von diesem Ansatz wäre also zuerst zu fragen: Was hast du getan, um deiner Applikation ihr Datenmodell bekannt zu machen?

Und als zweites würde ich aufwerfen: Wenn dir dein Datenmodell mit hundert Spalten in einer Tabelle zu aufwendig, kompliziert oder was auch immer ist: Warum änderst du es dann nicht? Immer wenn es Tabellen mit großer Anzahl von Spalten gibt, die mindestens mal den gleichen Spaltentyp besitzen, sollte sofort der Suchscheinwerfer im Bücherregal auf das Lehrbuch mit der Normalisierung gerichtet werden. Das riecht dann immer ziemlich nach Redundanz und Verstoß gegen Normalformen. Wobei sowas ja von Fall zu Fall nicht komplett schlecht sein muß, wenn man dadurch etwas wertvolleres gewinnt, wie z.B. Performance. Davon ist bei dir aber noch nicht wirklich die Rede.

- Sven Rautenberg

[Steel]

Nabend!

Ausgehend von diesem Ansatz wäre also zuerst zu fragen: Was hast du getan, um deiner Applikation ihr Datenmodell bekannt zu machen?

Ich hab da nix getan. Ich hab das Ding nicht angelegt.

Und als zweites würde ich aufwerfen: Wenn dir dein Datenmodell mit hundert Spalten in einer Tabelle zu aufwendig, kompliziert oder was auch immer ist: Warum änderst du es dann nicht? Immer wenn es Tabellen mit großer Anzahl von Spalten gibt, die mindestens mal den gleichen Spaltentyp besitzen, sollte sofort der Suchscheinwerfer im Bücherregal auf das Lehrbuch mit der Normalisierung gerichtet werden. Das riecht dann immer ziemlich nach Redundanz und Verstoß gegen Normalformen. Wobei sowas ja von Fall zu Fall nicht komplett schlecht sein muß, wenn man dadurch etwas wertvolleres gewinnt, wie z.B. Performance. Davon ist bei dir aber noch nicht wirklich die Rede.

Könnte man annehmen. Ist aber nicht so. In dieser Tabelle sind einfach alle Daten, die eine operation betreffen. Stell Dir vor du haettest ne große Firma. Es gibt 3 Schichten und jeden tag wird eingetragen, wann Schichbeginn sein soll, wann er war, wieviele Leute Urlaub hatten, wieviele Krankgeschrieben waren, wieviele wirklich fehlten, wie lange ien Band lief, ob es ausfälle gab,... Es gibt 3 Felder die den Schluessel ausmachen: Datum, Schicht und weil du nicht nur eine Niederlassung hast, sondern hundert, auch noch den Ort. Der Rest sind einfach ein Haufen Daten. Sicher kann man diese nach Thema trennen, aber das machts nicht grad übersichtlicher.

Es gibt noch X andere Tabellen, die z.B. die Orte nach kennzahlen aufschlüsseln, so daß man festlegen kann wer welche orte (länder) bearbeiten kann und so weiter und so fort. Aber das eigentliche Datenblatt befindet sich  in einer (nicht ganz kleinen) Tabelle.

Ändern? Könnte ich schon. Darf ich aber nicht.

Wenn nun jemand Daten eingeben will, wird geprueft, ob Daten für diesen Tag, Ort, Schicht, existieren. Wenn ja, is gut und die Daten werden geladen und angezeift. Man darf eingeben und updaten. Wenn nicht, auch kein Problem: Der Datensatz wird angelegt, mit lauter 0 oder leeren Textfeldern und die Eingabe kann beginnen. Aber nun sollen halt die Planzahlen (geplante Ankunft oder Abfahrtzeiten z.B.) vorgegeben werden. Die stehen in einer etwas kleineren Tabelle. Die im Grunde genauso aussieht wie die große. Der Unterschied ist halt daß dort nur die Felder mit den Planzahlen drin sind.

Kein Riss, nur lästig. Ich wüsste auch spontan nicht woher ich die Feldnamen der Plantabelle bekommen sollte ohne eine langes Query mit allen Feldnamen zu schreiben oder ohne eben die DB (in eben jener Tabelle) zu fragen, welche Felder das Baby denn hat. Ich könnte natuerlich die Tabelle auslesen und so an Felder und Inhalte kommen, mit denen ich dann ein Update erstelle. Aber das sind dann schon wieder 2 Schritte mit ner kleinen Zwischenlandung bei ASP(classic). (Es hat schon mehr als 2 Wochen gedauert, bis man - heisst drei bis vier Abteilungen - sich einig war, wie die Plantabelle auszusehen hat. Das kann sich immer und jederzeit ändern. Ein Grund sowas möglichst flexibel zu gestalten...)

Naja. Ich machs mir jetzt noch ein oder zwei Stunden gemütlich und geh dann ins Bett. Vor morgen will ich nicht mehr dran denken.

[Vinzenz Mai]

Hallo Steel,

Könnte man annehmen. Ist aber nicht so.

nach dem, was Du beschreibst, ist das so.

In dieser Tabelle sind einfach alle Daten, die eine operation betreffen. Stell Dir vor du haettest ne große Firma. Es gibt 3 Schichten und jeden tag wird eingetragen, wann Schichbeginn sein soll, wann er war, wieviele Leute Urlaub hatten, wieviele Krankgeschrieben waren, wieviele wirklich fehlten, wie lange ien Band lief, ob es ausfälle gab,... Es gibt 3 Felder die den Schluessel ausmachen: Datum, Schicht und weil du nicht nur eine Niederlassung hast, sondern hundert, auch noch den Ort. Der Rest sind einfach ein Haufen Daten. Sicher kann man diese nach Thema trennen, aber das machts nicht grad übersichtlicher.

Vieles sind einfach Ereignisse.

Kein Riss, nur lästig. Ich wüsste auch spontan nicht woher ich die Feldnamen der Plantabelle bekommen sollte ohne eine langes Query mit allen Feldnamen zu schreiben

das ist doch überhaupt kein Problem - und kann ist garantiert wartbarer als
Deine folgenden Ideen.

oder ohne eben die DB (in eben jener Tabelle) zu fragen, welche Felder das Baby denn hat. Ich könnte natuerlich die Tabelle auslesen und so an Felder und Inhalte kommen, mit denen ich dann ein Update erstelle.

(Es hat schon mehr als 2 Wochen gedauert, bis man - heisst drei bis vier Abteilungen - sich einig war, wie die Plantabelle auszusehen hat. Das kann sich immer und jederzeit ändern. Ein Grund sowas möglichst flexibel zu gestalten...)

Wenn sich häufig etwas ändern kann, dann gehört das typischerweise in Zeilen, nicht in Spalten :-)

Freundliche Grüße

Vinzenz