Optionsgruppen in MSSQL

PeterS

Aktiver Benutzer
Beiträge
27
Ich erinnere aus alten ACCESS-Zeiten noch der Vorzüge von Optionsgruppen, suche dergleichen aber in MS SQL bisher vergeblich.

Könnte mir vielleicht jemand mit einem Denk-/Strukturansatz auf die Sprünge helfen?

2 Tabellen in 1:n-Relation: [tb_ADRESSEN] und [tb_ANSPRECHPARTNER]. Alle Ansprechpartner sollen auch in [tb_ADRESSEN] geführt werden. Zu jedem Set in [tb_ADRESSES] kann es mehrere Ansprechpartner geben. Es soll aus mehreren Ansprechpartnern stets nur 1 Hauptansprechpartner ausgewählt werden können; bei nur einem Eintrag soll der Hauptansprechpartner sein.

Wie kann ich sowas in MS SQL erreichen?

Dank und Grüße, PeterS
 
Werbung:
Alle Ansprechpartner sollen auch in [tb_ADRESSEN] geführt werden.
Warum? In welcher Form?

Grundsätzlich Fremdschlüssel, Beispiel:
Code:
CREATE TABLE tbl_unternehmen (
   pk UNIQUEIDENTIFIER PRIMARY KEY,
   firma VARCHAR(100) NOT NULL
   );

CREATE TABLE tbl_personen (
   pk UNIQUEIDENTIFIER PRIMARY KEY,
   name VARCHAR(100) NOT NULL
   );

CREATE TABLE tbl_ansprechpartner (
   pk UNIQUEIDENTIFIER PRIMARY KEY,
   fk_unternehmen UNIQUEIDENTIFIER NOT NULL,
   fk_person UNIQUEIDENTIFIER NOT NULL,
   istHauptansprechpartner BIT
   );

ALTER TABLE tbl_ansprechpartner ADD CONSTRAINT con_ap_unt FOREIGN KEY(fk_unternehmen) REFERENCES tbl_unternehmen(pk);
ALTER TABLE tbl_ansprechpartner ADD CONSTRAINT con_ap_per FOREIGN KEY(fk_personen) REFERENCES tbl_personen(pk);
Dazu dann am besten einen CHECK-Constraint und eine Funktion (keinen weiteren Trigger), wie hier in Lösung 2:
Looking for SQL constraint: SELECT COUNT(*) from tBoss < 2
 
Warum? In welcher Form?

Ziel ist eigentlich nur, z.B. alle Personennamen und ggf. zugehörige Adressen, E-Mail etc. im Systems an einer einzigen Stelle recherchieren zu können. Sie können mal in Privatadressen stehen, mal in Mitarbeiteradressen (Nebenadressen) unterhalb der Firma/Abteilung.

UND: Als Teilnehmernamen bei Seminaren werden nur solche Nebensätze als Ansprechpartner n ach LX synchronisiert. Irgendwie müssen die Teilnehmernamen mit auf die LX-Rechnung kommen.

Vielleicht ein falscher Ansatz?
 
Zuletzt bearbeitet von einem Moderator:
Nicht zwingend, ich verstehe das so das du mehrere Tabellen mit Adressen hast. Aus meiner Sicht eine schlechte Datensturkur und schlecht normalisiert, ich würde eine Adresse immer in der selben Tabelle speichern und dann dem anderen Objekt zuordnen.

Du kannst dir ansonsten eine Sicht zusammen bauen die alle Adressen aus allen Tabellen untereinander auflistet, wäre das nützlich?
 
Das mit einer 'Sicht' ist wahrscheinlich die beste Lösung. Habe nur so garkeine Idee, wie ich die im Cobra-Frontend nutzbar machen soll. Da geht alles über Tabellen, die per Frontend angelegt wurden. Unter 'NEU' gibt's in der Datenbankverwaltung nur 'Tabellen' oder 'Brückentabellen' (was auch immer das sein mag).

°° [mehrere Tabellen mit Adressen]
Nö. Alles passiert in [dbo].[ADRESSES], aber daraus werden eben auch keinerlei Teile relational ausgelagert. Ich kann nur Datensätze aus [ADRESSES] in eine 1-stufige Hierarchie mit Haupt- und Nebensätzen einhängen und dann festlegen, welche Felder des Hauptsatzes auf die Nebensätze synchronisieren sollen. Wenn eine Firma Mitarbeiter in 50 Nebensätzen hat und einzelne dieser Nebensätze als Postanschrift nutzbar sein sollen, stehen Firma, Ortsteil, Straße, Hausnummer, PLZ, Ort 50 mal mit identischen Angaben im System. Jeder Nebensatz enthält das komplette Paket postalischer Angaben.

Das Hierarchiespiel läuft übrigens anscheinend als Hack oder Trigger im Backend und ist im Frontend nur sehr beschränkt nutzbar. Import von hierarchisch vorbereiteten Sets über das Frontend geht z.B. garnicht.
 
Also "Brückentabellen" sind definitiv Zwischentabellen, also die Abbildung von n:m-Beziehungen. In meinem Beispiel wäre tbl_ansprechpartner so eine Tabelle, die n:m-Beziehung zwischen Unternehmen und Personen.

Ja deine Tabelle ADRESSES ist genau der Grund warum ich mich mal gegen Cobra und für ein ähnliches Produkt entschieden habe, ich finde das gruselig. Hauptsätze und Nebensätze müssen hier per Trigger synchron gehalten werden, anders geht es überhaupt nicht weil SQL so einen Quark eigentlich nicht vorsieht. Tatsächlich müsste das relational abgebildet werden wenn man es richtig macht.

Ich kann dich nur dahingehend trösten das man die Trigger ja einsehen kann also auch nachvollziehen kann was die da tun. Theoretisch könnte man auf die Idee kommen das tatsächlich zusätzlich in relationale Tabellen zu schreiben, es erfordert in jedem Fall viel Sorgfalt das anzupassen.
 
Ich hatte auch schon mal daran gedacht, für wichtige Routinen eine Art Parallelsystem zu entwickeln und die Cobra-Default-Tabellen nur noch per Trigger oder so zu benutzen. Aber bedeutet riesigen Aufwand und bleibt stets sehr dünnes Eis mit Blick auf den nächsten Releasewechsel, wo dann sicherlich alles Mögliche nicht mehr funktionieren wird. Das Gesamtsystem muß (auch jetzt) stets benutzbar und einsatzfähig bleiben, was selbst kleinere ergänzende Basteleien schwierig macht. Und nicht alles, was da in fast einem Jahrzehnt reingeschrieben worden ist, läßt sich von jetzt auf gleich in neue Strukturen überführen (die gesamte Kontakt- und Aktivitätenverwaltung scheint z.B. auch sehr mit heißer Nadel genäht und ist - wen überrascht's - mal wieder so gut wie garnicht dokumentiert).

Aber hier und heute erstmal vielen Dank für Deine Hilfe, ich werde mal einen Code für das Optionsgruppenspiel basteln und schauen, was so passiert und wie's aussieht. Sollte mich wundern, wenn das alles gleich laufen würde.
 
Einen Vorteil haben so gewachsene Strukturen und Fuschereien, die Entwickler haben selbst keinen Drang mit einem "Update" wirklich etwas daran zu ändern. Daher solltest du da langfristig erstmal weniger zu befürchten haben.

Aber du hast Recht, es ist viel Arbeit.
 
Heute kündigte sich gerade wieder die nächste Cobra-Baustelle an: an Teilnehmeradressen, die sich für eine bestimmte Veranstaltung angemeldet haben, sollen Serienmails mit verschiedenen Details für eine bestimmte Veranstaltung gesendet werden. Das Ganze läuft über 3 Tabellen: [ADRESSES], [VERANSTALTUNGEN], [VERANSTALTUNGEN-TEILNEHMER], die miteinander in Beziehung stehen. Nur aus [ADRESSES] kann ich die benötigten Feldinhalte als Variablen in eine Serienmail ziehen.
Ich werde also wohl nicht umhin kommen, in [ADRESSES] irgendwelche Zusatzfelder temporär mit den benötigten Inhalten zu befüllen. Also geht's wohl wieder in Richtung Trigger-Job...
Könntest Du mir bitte mal mit einem Programmier-Ansatz weiterhelfen? Der Trigger sollte sicherlich auf [VERANSTALTUNGEN] feuern und da durch eine Feldänderung (z.B. 'Serienmail vorbereiten' - J/N) ausgelöst werden --- der Trigger selektiert über die Beziehungen id.[VERANSTALTUNGEN] = id1.[VERANSTALTUNGEN-TEILNEHMER] und id.[ADRESSES] = id2.[VERANSTALTUNGEN-TEILNEHMER] alle relevanten Adressen und füllt dann per Update die Temporärfelder.
Wie aber erreiche ich, dass am Ende des Jobs (Serienmail ist versendet) ohne zusätzlichen Benutzereingriff alles wieder in den Ausgangszustand kommt, also das Feld (z.B. 'Serienmail vorbereiten' - J/N) wieder auf 'N' gesetzt und die Temporärfelder wieder geleert werden? Ich würde gern vermeiden, einen weiteren - sagen wir 'Clearing'-Trigger durch Änderung eines weiteren Felder neuerlich feuern zu lassen.
 
Also das geht natürlich durch Trigger (die müssten sowohl auf VERANSTALTUNGEN als auch auf VERANSTALTUNGEN-TEILNEHMER und vermutlich auch auf ADRESSES] feuern um es richtig zu machen). Das ist ziemlich tricky, daher würde ich dir zunächst mal nur zu einem Script raten.

Bei so einer Versand-Aktion liegt der Vorteil darin das du das Script einmalig ausführen kannst (um die Adressen "aufzubereiten"), dann kannst du den Versand starten (das geht vermutlich über Cobra selbst?), und zum Schluss löscht du wieder den Inhalt deiner Spalte.

Wenn das läuft kann man sich immernoch an Trigger machen.
 
Werbung:
Einfach eine Liste von SQL-Queries die du ausführst bevor du deine Serienmail generierst. Die bereiten dann die Versanddaten auf.

Das geht übers Management Studio oder mit xp_cmdshell auch über die Eingabeaufforderung oder aus einem Task heraus.
 
Zurück
Oben