Glengamoi · AspHeute (Artikel) · .NET Heute (RSS-Suche) · .NET Blogs · Glengamoi Suche (Installieren via Klick)

Glengamoi

Die Diskussionsforen der deutschen .NET Community
Willkommen bei Glengamoi. Anmeldung | Registrieren | Hilfe
in Suchen

Stored Procedures

Letzter Beitrag 10-16-2006 23:09 von BernhardGrojer. 9 Antworten.
Seite 1 von 1 (10 Treffer)
Beiträge sortieren: Zurück Weiter
  • 10-11-2006 10:34

    Stored Procedures

    Hi!

    Ich möchte Daten in die Datenbank Updaten. Die Idee ist es dafür eine Stored Procedures zu verwenden. Ich verfolge in meiner Businesslogic alle Änderungen und möchte dann natürlich nur die tatsächlich geänderten Felder Updaten. 

    Ist es möglich eine StoredProcedure zu entwerfen die mir "Variable" Anzahl von Variablen entgegenimmt? Bzw. die nur die Felder Updated bei denen ich etwas übergebe?

     Ich hoff ihr wisst was icih meine!

    Abgelegt unter: ,
    • IP-Adresse ist Registriert
  • 10-11-2006 10:42 Antwort zu

    RE: Stored Procedures

    Hallo,


    >Ich möchte Daten in die Datenbank Updaten.
    >Die Idee ist es dafür eine Stored Procedures zu verwenden.
    >Ich verfolge in meiner Businesslogic alle Änderungen und
    >möchte dann natürlich nur die tatsächlich geänderten Felder Updaten.

    >Ist es möglich eine StoredProcedure zu entwerfen die mir "Variable"
    >Anzahl von Variablen entgegenimmt? Bzw. die nur die Felder Updated
    >bei denen ich etwas übergebe?

    http://weblogs.asp.net/rmclaws/archive/2004/02/18/75381.aspx

    Gruss

    Alex
    http://blogs.dotnetgerman.com/alexonasp.net
    • IP-Adresse ist Nicht registriert
  • 10-11-2006 10:42 Antwort zu

    Re: Stored Procedures

    At 10:34 AM 10/11/2006, you wrote:
    >Ist es möglich eine StoredProcedure zu entwerfen
    >die mir "Variable" Anzahl von Variablen
    >entgegenimmt? Bzw. die nur die Felder Updated bei denen ich etwas übergebe?

    Halte ich für keine gute Idee - zur Not noch
    sprocs für bestimmte "Blöcke von Feldern" die
    häufig gemeinsam geändert werden. Aber ansonsten
    vervielfacht sich der Wartungsaufwand.

    Chris
    • IP-Adresse ist Nicht registriert
  • 10-12-2006 9:13 Antwort zu

    AW: Re: Stored Procedures

    Christoph Wille:
    Halte ich für keine gute Idee - zur Not noch sprocs für bestimmte "Blöcke von Feldern" die häufig gemeinsam geändert werden. Aber ansonsten vervielfacht sich der Wartungsaufwand. Chris

    Hallo Chris!

    Würdest du immer alle Felder Updaten beim Speichern eines Businessobjects? Eigentlich wollte ich genau das vermeiden und nur wirklich geänderte Felder speichern. Dafür wollte ich auch immer nur EINE sprocs pro Objekt/Update haben der ich eben nur die tatsächlichen Felder übergebe. (Stichwort: Wartungsaufwand)
    Ich denke das würd die Wartung erleichtern und nicht "komplizierter" machen. Die Anwendung würde lebendiger werden da ich ich sperren nur noch auf Feldebene habe (2 User ändern das selbe Objekt. Der der nachträglich speichert killt die Änderungen des erstens. Auf Feldebene hätte ich das Problem nicht.) Ich denke das wäre eine sehr feiner Lösungsansatz.

    • IP-Adresse ist Registriert
  • 10-12-2006 9:32 Antwort zu

    AW: Re: Stored Procedures

    Hallo Bernhard,

    ich habe auch lange darüber gegrübelt, wie ich dies am besten regele. Ich habe mich ebenfalls für "Blöcke von Feldern" (Christoph Wille) entschieden.

    Als Idee hatte ich noch Folgendes (nur kurz hingetippt):

    create procedure ChangeAdresseString( Feldname char(32), Feldinhalt varchar(255), Nr integer )
    if (Feldname = "Feld1" )
    then update Adresse set Feld1 = :Feldinhalt where ID = :Nr;
    else begin
    if (Feldname = "Feld2" )
    then update Adresse set Feld2 = :Feldinhalt where ID = :Nr;
    end
    /* usw. */

    Aber das ist natürlich alles andere als übersichtlich... Jürgen
     

    Software für Verlage
    #D für NET 2.0, dazu Firebird 2.0 und Firebird Net Provider
    vorher: Delphi 5 Pro, Delphi 2005 Pro mit C# (also NET 1.1)
    • IP-Adresse ist Registriert
  • 10-12-2006 9:40 Antwort zu

    RE: Stored Procedures

    > Dafür wollte ich auch immer nur EINE sprocs pro Objekt/Update
    > haben der ich eben nur die tatsächlichen Felder übergebe.

    alternativ könntest du eine storedproc mit allen parametern machen - dort wo
    NULL übergeben wird (= keine änderung) lässt du in der storedproc das
    statement dann aus.
    >
    > Der der nachträglich speichert killt die Änderungen des erstens.
    > Auf Feldebene hätte ich das Problem nicht.

    ich persönlich kann mich mit so einer vorgangsweise überhaupt nicht
    anfreunden.
    meines erachtens sollten hier immer parent-child relationen zum einsatz
    kommen.
    bei änderungen wird ein neues child geschrieben und das alte deaktiviert
    (nicht gelöscht, nicht überschrieben).
    mehrere vorteile:
    - du kannst nachvollziehen wer wann welche änderung gemacht hat
    - du kannst dich in anderen abfragen auf frühere werte beziehen
    - die datenkonsistenz generell profitiert davon
    lg, christian
    • IP-Adresse ist Nicht registriert
  • 10-12-2006 10:08 Antwort zu

    AW: RE: Stored Procedures

    Alexander Zeitler:
    http://weblogs.asp.net/rmclaws/archive/2004/02/18/75381.aspx

    Hallo Alex! Danke für den Link! Hat mich ja schonmal auf Ideen gebracht.

    juetho_berlin:
    ich habe auch lange darüber gegrübelt, wie ich dies am besten regele. Ich habe mich ebenfalls für "Blöcke von Feldern" (Christoph Wille) entschieden.

    Naja ich hätte gern so wenig SP wie nötig. Am besten nur eine fürs Update (u. Insert?). Und eben nicht alles übergeben "müssen" beim Update. Das würd die Wartung erleichtern. Im Moment "generiere" ich dafür eben dynmaisch Update Querys die nur die betroffenen Felder ändert. Nur is das eben eher unfein. (jedes mal generieren müssen bei jedem Update ist nichts wirklich meins)

    christian marin:
    alternativ könntest du eine storedproc mit allen parametern machen - dort wo NULL übergeben wird (= keine änderung) lässt du in der storedproc das statement dann aus.

    Genau das wollte ich eigentlich tun. Aber dann muss ich ja erst wieder überall "NULL" übergeben.
    Ich wollte eigentlich beim aufruf eher nur
    cmd.paramters.addwithvalue("@ID", 123)
    cmd.paramters.addwithvalue("@FirstName", "xxx")
    übergeben.
    Und eben zB kein "@LastName" übergeben. Kann ich dann in der SP abfragen ob etwas übergeben wurde oder ob DbNull.Value übergeben wurde? Wenn ich Null übergebe kann ich ja nicht unterscheiden ob ich das Feld jetzt auf NULL setzen will oder das Feld einfach nicht updaten.

    Ein "Versionstracking" möchte ich eventuell später implementieren. (Nicht auf Datenbankebene sondern im Businesslayer). Gespeichert eventuell Async in eine andere Datenbank. Das weiß ich allerdings noch nicht so genau und ist auch nur optional.
    Die richtige Datenbank möchte ich allerdings schon Updaten.

    • IP-Adresse ist Registriert
  • 10-12-2006 10:09 Antwort zu

    AW: RE: Stored Procedures

    Danke euch allen nochmals für die Antworten. Ich hab leider (noch) wenig Ahnung von SP und versuch gerade mich einzulesen.

    Ich hab hier mal ein Beispiel für Update geschrieben:
    Wäre fein wenn noch wer von euch ein paar Zeilen dazu sagen könnte!

    SP für Update/Insert von einem Eployee BO:

    CREATE PROCEDURE SaveEmployee
    (
     @ID bigint,
     @FirstName varchar(50),
     @LastName varchar(50)
    )
    AS
    IF @ID = 0 OR @ID = -1
    BEGIN
     INSERT INTO tblEmployee
     (FirstName, LastName)
     VALUES
     (@FirstName, @LastName);
     SELECT SCOPE_IDENTITY AS [SCOPE_IDENTITY];
    END
    ELSE
    BEGIN
     /*
     Select * tblEmployee WHERE ID = @ID
     SET VALUES ?!?
     */

     UPDATE tblEmployee
     SET
     FirstName = @FirstName
     LastName = @LastName
     WHERE ID = @ID;
     SELECT @ID;
    END


    Kann ich in der SP nicht "abfragen" ob ein Wert für ein Feld gesetzt/übergeben wurde?

    Also zB ein

    Select * From tblEmployee Where ID = @ID in der SP.

    ausführen und die Werte die Fehlen mit den Daten von dem Select befüllen? Es würden dann zwar immer noch alle Felder updated werden aber mit den aktuellen Werten der DB. Die Kosten für das zusätzliche Select nehm ich gern in kauf.

    • IP-Adresse ist Registriert
  • 10-12-2006 11:13 Antwort zu

    AW: RE: Stored Procedures

    Bernhard Grojer:
    Kann ich in der SP nicht "abfragen" ob ein Wert für ein Feld gesetzt/übergeben wurde?

    Das ist relativ einfach; ich kopiere hier eine Prozedur, die ich für dieses Verfahren erstellt habe (Fehlerprüfungen, ob der Datensatz vorhanden ist, u.dgl. habe ich entfernt). Ich möchte Dich vor allem auf Abschnitt 5.2 hinweisen:

    /* Nr ist die ID der Tabelle, Daten und Nutzer sind Felder, die geändert werden können */
    ALTER PROCEDURE Formular_Save
            ( Nr INTEGER, Daten_Nr INTEGER, Nutzer_Name VARCHAR(35)  )
    AS
      DECLARE VARIABLE alt_Daten      INTEGER;
      DECLARE VARIABLE alt_Nutzer VARCHAR(35);
    BEGIN
      /**  (5.1)  alte Feldinhalte uebernehmen  **/
      SELECT Daten, Nutzer
        FROM Formular     WHERE ID = :Nr
        INTO :alt_Daten, :alt_Nutzer;

      /**  (5.2)  neue Feldinhalte pruefen  **/
      IF (Daten_Nr IS NULL)
        THEN Daten_Nr = alt_Daten;
      IF (Nutzer_Name IS NULL)
        THEN Nutzer_Name = alt_Nutzer;

      /**  (5.3)  Aenderungen speichern  **/
      UPDATE Formular
         SET Daten    = :Daten_Nr,
            Nutzer = :Nutzer_Name
       WHERE ID = :Nr;
    END

     Bringt Dich das weiter? Gruß Jürgen

     

    Software für Verlage
    #D für NET 2.0, dazu Firebird 2.0 und Firebird Net Provider
    vorher: Delphi 5 Pro, Delphi 2005 Pro mit C# (also NET 1.1)
    • IP-Adresse ist Registriert
  • 10-16-2006 23:09 Antwort zu

    AW: RE: Stored Procedures

    Danke für das Codebeispiel!

    Bringt mir definitv etwas denk ich! Ich weiß nur noch nicht wie ich unterscheiden kann, ob jetzt "nichts" übergeben wurde oder DBNull. Ich weiß auch noch nicht was beim Aufruf  passiert wenn ich nur ein "paar" Parameter hinzufüge. Das werd ich ausprobieren wenn ichs umsetzen versuchen.

     Auf jeden Fall Danke!

    • IP-Adresse ist Registriert
Seite 1 von 1 (10 Treffer)