Mehrere Datenbank Aktionen...

[Tobi]

Hallo zusammen,

ich bastele an einem ASP/VBScript backend fuer eine M$ Access DB. Bin neu auf dem Gebiet.

Folgendes Problem beim Hinzufuegen eines neuen Datensatzes:
Zusammen mit dem Form zum Hinzufuegen eines neuen Datensatzes kann auch ein Point of Contact aus einer anderen Tabelle (Dropdown Feld) dem Datensatz zugefuegt werden. Struktur der DB sieht wie folgt aus:

+--------------+       +--------------+        +--------------+
| Datensaetze  |       |   Relation   |        |      POC     |
+--------------+   1:n +--------------+        +--------------+
| DS_ID        |-------| DS_ID        |   1:1  | LAST_NAME    |
| TITLE        |       | POC_ID       |--------| POC_ID       |
| ETC          |       | RL_ID        |        | FIRST_NAME   |
+--------------+       +--------------+        +--------------+

Wenn ich in dem Form einen neuen Datensatz hinzufuege, dann ist logischerweise noch kein DS_ID vorhanden, den ich in die Tabelle Relationen einfuegen kann.

Muss ich jetzt wirklich:
1. den Insert in Datensaetze machen,
2. mit Select die DS_ID auslesen,
3. einen Insert in Relation machen,

oder geht das auch einfacher (in einem Rutsch)? Ist meine Datenbank Struktur vielleicht doch nicht gut? Ausserdem sollen auch mehrere POCs einem Datensatz zugefuegt werden koennen.

Hat jemand Anregungen fuer mich?

Vielen Dank im Voraus & Gruss,
Tobi

[Michael Schröpl]

Hi Tobi,

Muss ich jetzt wirklich:

1. den Insert in Datensaetze machen,

ja.

2. mit Select die DS_ID auslesen,

Nein - denn den hast Du ja noch in den Daten, die Du im 1. Schritt eingefügt hast.

3. einen Insert in Relation machen,

Ja.

oder geht das auch einfacher (in einem Rutsch)?

Es geht nicht mit einem SQL-Statement. Es sollte aber in einem "Rutsch" gehen, d. h. als unteilbare Operation - sprich: Du solltest beide Statements als Transaktion laufen lassen.

Ist meine Datenbank Struktur vielleicht doch nicht gut?

Das, was Du bisher über die Tabellen beschrieben hast, finde ich okay.
Von den Feldern selbst hast Du ja nichts erzählst ... falls Du das noch tun solltest und dabei der Begriff "autoincrement" fallen sollte, werde ich Dich dafür _nicht_ loben. ;-)

Ausserdem sollen auch mehrere POCs einem Datensatz zugefuegt werden koennen.

Innerhalb eines SQL-Statements - nein.

Deine 3GL-API bietet Dir aber möglicherweise eine Methode an, nicht nur in einer Schleife einzelne Statements abzufeuern, sondern ggf. einen Array an Datensätzen in eine Tabelle zu schießen. (Das bewirkt intern fast dasselbe - bloß der Code-Generator muß etwas weniger arbeiten.)

Viele Grüße
      Michael

[Tobi]

Hallo Michael,

danke fuer Deine schnelle Antwort.

2. mit Select die DS_ID auslesen,

Nein - denn den hast Du ja noch in den Daten, die Du im 1. Schritt eingefügt hast.

Nein, habe ich nicht, da DS_ID der Primaerschluessel ist, der per autoincrement (!!! ;oD) automatisch generiert wird! (Genauso, wie alle anderen IDs)

oder geht das auch einfacher (in einem Rutsch)?

Es geht nicht mit einem SQL-Statement. Es sollte aber in einem "Rutsch" gehen, d. h. als unteilbare Operation - sprich: Du solltest beide Statements als Transaktion laufen lassen.

Aha. Transaktion, habe ich schon mal gehoert.....was sind Transaktionen? So eine Art Koppelung mehrerer Aktionen, z.B. Inserts? Geht das mit M$ Access?
Bin - wie gesagt - neu auf dem Gebiet, muss dazu wohl mal googeln.

Ist meine Datenbank Struktur vielleicht doch nicht gut?

Das, was Du bisher über die Tabellen beschrieben hast, finde ich okay.
Von den Feldern selbst hast Du ja nichts erzählst ... falls Du das noch tun solltest und dabei der Begriff "autoincrement" fallen sollte, werde ich Dich dafür _nicht_ loben. ;-)

DS_ID, RL_ID und POC_ID sind Primaerschluessel (ja mit autoincrement - war Deine Anmerkung jetzt ironisch oder ist das nicht gut?)

Ausserdem sollen auch mehrere POCs einem Datensatz zugefuegt werden koennen.

Innerhalb eines SQL-Statements - nein.

Koennte ich da nicht ein Multi-Select Formfeld machen und dann ein Insert in einer Schleife?

Deine 3GL-API bietet Dir aber möglicherweise eine Methode an, nicht nur in einer Schleife einzelne Statements abzufeuern, sondern ggf. einen Array an Datensätzen in eine Tabelle zu schießen. (Das bewirkt intern fast dasselbe - bloß der Code-Generator muß etwas weniger arbeiten.)

Ahhhh...ok...das ist mir zu hoch...langsam:
-Was ist 3GL-API? Sowas wie OLEDB? Eine DB Schnittstelle?
-Einen Array mit mehreren Datensaetzen in DB einfuegen? Das geht mit Access?

Vielen Dank & Gruss
Tobi

[Michael Schröpl]

Hi Tobi,

Nein, habe ich nicht, da DS_ID der Primaerschluessel ist, der per autoincrement (!!! ;oD) automatisch generiert wird! (Genauso, wie alle anderen IDs)

dann hast Du Dir Dein Problem selbst gemacht.

Aha. Transaktion, habe ich schon mal gehoert.....was sind Transaktionen? So eine Art Koppelung mehrerer Aktionen, z.B. Inserts?

Ja. Eine transaktionsfähige Datenbank kann eine Liste von Statements erst mal "versuchsweise" ausführen, und erst wenn alles funktioniert hat, tritt die Gesamtheit "in Kraft", wird also für andere Anwendungen sichtbar. (Das funktioniert intern mit einem separaten Log pro Transaktion, welches dem RDBMS erlaubt, Operationen auch wieder rückgängig zu machen.)

Geht das mit M$ Access?

Hm ... ich möchte es fast bezweifeln, aber ... RTFM.

Bin - wie gesagt - neu auf dem Gebiet, muss dazu wohl mal googeln.

Genau deshalb habe ich Dir den Suchbegriff geliefert. ;-)

DS_ID, RL_ID und POC_ID sind Primaerschluessel (ja mit autoincrement - war Deine Anmerkung jetzt ironisch oder ist das nicht gut?)

Ich mag keine autoincrements. Sie hindern mich daran, mit einer Tabelle viele Dinge zu tun, die ich gerne tun können will.
Für mich sind Relationen Mengen ... und ich kann nun mal nicht eine Teilmenge aus einer Deiner Tabellen in eine temporäre Tabelle kopieren, etwas darin ändern (z. B. einen "Klon" herstellen) und das Ergebnis zurück kopieren, weil mich genau daran die autoincrement-Spalte hindert, in die man keine Werte explizit einfügen kann. Ich kann dann kein INSERT INTO TABLE SELECT ... FROM klon im Dialog eingeben ... ich bin gezwungen, in einer 3GL eine Schleife zu programmieren.

Ausserdem sollen auch mehrere POCs einem Datensatz zugefuegt werden koennen.
Innerhalb eines SQL-Statements - nein.
Koennte ich da nicht ein Multi-Select Formfeld machen und dann ein Insert in einer Schleife?

Was Du auf der Ebene Deiner algorithmischen Sprache (3GL) tust, ist Deine Sache (Du kannst Deine Operation z. B. gegenüber ihrem Aufrufer als Funktion einschalen, d. h. Dein Datenmodell vor ihm verstecken) - gegenüber der SQL-Schnittstelle brauchst Du aber einzelne Statements.

-Was ist 3GL-API?

Eine 3GL ist eine Programmiersprache der 3. Generation, also etwas, wo Du einen Lösungsweg (Algorithmus) beschreibst. Bei SQL tust Du genau das nicht - Du beschreibst nur, welche Eigenschaften das Ergebnis haben soll ... wie das RDBMS das hinkriegt, ist seine Sache.

Und eine API ist ein application interface ... in Deinem Fall üblicherweise eine Definition von Funktionsaufrufen (in Deiner 3GL gibt es ja Funktionen als Ablaufträger), welche Dir erlauben, SQL in diese Sprache "einzubetten".

-Einen Array mit mehreren Datensaetzen in DB einfuegen? Das geht mit Access?

Auch da kann Dir ich nur wieder ein herzliches RTFM spendieren ... in Oracle geht es, beispielsweise.

Viele Grüße
      Michael

[Tobi]

Hallo Michael,

dann hast Du Dir Dein Problem selbst gemacht.

Ueberall steht, man soll mit eindeutigen IDs arbeiten und mit autoincrement....wie kriegt man sonst einen Primaerschluessel hin? Auf Seiten der 3GL?

Genau deshalb habe ich Dir den Suchbegriff geliefert. ;-)

Ja, habe ich gemerkt ;o), danke fuer das Stichwort!
Habe aber dank Deiner kurzen Erklaerung schon mal das Prinzip verstanden...

DS_ID, RL_ID und POC_ID sind Primaerschluessel (ja mit autoincrement - war Deine Anmerkung jetzt ironisch oder ist das nicht gut?)

Ich mag keine autoincrements. Sie hindern mich daran, mit einer Tabelle viele Dinge zu tun, die ich gerne tun können will.
Für mich sind Relationen Mengen ... und ich kann nun mal nicht eine Teilmenge aus einer Deiner Tabellen in eine temporäre Tabelle kopieren, etwas darin ändern (z. B. einen "Klon" herstellen) und das Ergebnis zurück kopieren, weil mich genau daran die autoincrement-Spalte hindert, in die man keine Werte explizit einfügen kann. Ich kann dann kein INSERT INTO TABLE SELECT ... FROM klon im Dialog eingeben ... ich bin gezwungen, in einer 3GL eine Schleife zu programmieren.

Da stoesst man wohl an die Grenzen dieses eigentlich zur Erleichterung gedachten Hilfsmittels....

Was Du auf der Ebene Deiner algorithmischen Sprache (3GL) tust, ist Deine Sache (Du kannst Deine Operation z. B. gegenüber ihrem Aufrufer als Funktion einschalen, d. h. Dein Datenmodell vor ihm verstecken) - gegenüber der SQL-Schnittstelle brauchst Du aber einzelne Statements.

Verstanden.

-Was ist 3GL-API?

Eine 3GL ist eine Programmiersprache der 3. Generation, also etwas, wo Du einen Lösungsweg (Algorithmus) beschreibst. Bei SQL tust Du genau das nicht - Du beschreibst nur, welche Eigenschaften das Ergebnis haben soll ... wie das RDBMS das hinkriegt, ist seine Sache.
Und eine API ist ein application interface ... in Deinem Fall üblicherweise eine Definition von Funktionsaufrufen (in Deiner 3GL gibt es ja Funktionen als Ablaufträger), welche Dir erlauben, SQL in diese Sprache "einzubetten".

Also ist in meinem Fall praktisch das Loesungswegsgeruest bestehend aus VBScript (verwendete Sprache/Code) Funktionen damit gemeint, das aber ueber SQL mit dem RDBMS kommunizieren kann?

-Einen Array mit mehreren Datensaetzen in DB einfuegen? Das geht mit Access?

Auch da kann Dir ich nur wieder ein herzliches RTFM spendieren ... in Oracle geht es, beispielsweise.

Ich wuerde ja auch gerne mit einer professionellen DB arbeiten ;o), aber habe leider nur Access zur Verfuegung...PostgreSQL waere vielleciht der naecshte Schritt....

Vielen Dank, Du hast mir schon sehr weitergeholfen,

Gruss,
Tobi

[Andreas Korthaus]

Hi Michael!

Nein, habe ich nicht, da DS_ID der Primaerschluessel ist, der per autoincrement (!!! ;oD) automatisch generiert wird! (Genauso, wie alle anderen IDs)

dann hast Du Dir Dein Problem selbst gemacht.

Wieso eigentlich? "gute" RDBMS haben kein autoincrement... aber warum nicht? Die ID ist nur für die interne Datenhaltung notwendig, wieso soll sich mein Programm damit auseinander setzen?

Aus diesem Grund wird das auch von PEAR nicht unterstützt, da gibt es eine Methode die erst die nächte ID zu ermitteln und die dann zu verwenden - aber wieso bitte? Für mich sieht das erheblich fehleranfälliger aus wenn ich erst eine ID ermittle, diese ausgebe, dann einen Datensatz mit der nächst höheren eintrage... und damit das sicher wird muss alles in ein table-LOCK oder eine Transaktion. Was um himmelsillen ist daran besser als das der DB selbst zu überlassen?

Viele Grüße
Andreas