Hallo! > > Ich hab jetzt beide Varianten einmal getestet, allerdings noch ohne > > MS-Stress. > > > > Testverlauf: > > > > 1. 10.000 Datens�tze eingef�gt (10.000 INSERT-Statements) > > 2. 10.000 Datens�tze sortiert gelesen (1 SELECT-Statement) > > 3. 10.000 Datens�tze per Index gelesen (10.000 SELECT-Statements) > > 4. 10.000 Datens�tze gel�scht (1 DELETE Statement) > > > > Die zweite Datenbank enth�lt nur eine View: > > SELECT * FROM test IN datenbank.mdb > > Ist das wirklich das gleiche wie ein Link? > Vielleicht wird bei einem Link schon beim Connection die andere Datei > mit ge�ffnet und bei diesem View erst beim ansprechen des Views... > Es k�nnten auch andere Caching-Mechanismen verwendet werden... > Vielleicht macht das einen Unterschied....
Sehr wahrscheinlich. Auf jeden Fall wird die Verbindung zum Back-End erst mit der View aufgebaut, also immer wieder neu. Eine st�ndige Verkn�pfung wie zwischen Front-End und Back-End normalerweise �blich, kann ich im Web nicht verwenden, da weder VBA noch der Verkn�pfungsmanager gestartet werden k�nnen. Vielleicht gibt es da noch was im Connection-String. Das muss ich noch pr�fen. > > Ergebnis: > > > > Entscheidend ist nur die Zeit, die f�r den Aufbau der Verbindung > > ben�tigt wird. Der Unterschied in den F�llen, wo ein einzelnes INSERT- > > oder SELECT- oder DELETE-Statement ausgef�hrt wird, ist in VBScript > > nicht messbar. Nur wenn man mehrere Statements hintereinander ausf�hrt > > gibt es messbare Unterschiede, wobei die Verkn�pfungen etwa 2 > > bis 6 mal > > mehr Zeit ben�tigen. > > > > F�r die Praxis ergeben sich also keine messbaren Performance-Einbu�en. > > Sicher? Kann man den 6-fachen Connection-Aufbau nicht so interpretieren, > dass man nur noch ein sechstel der Nutzer bedienen kann? > Da muss wohl doch MS-Stress ran... Ja, und dann kommt's wieder auf das Connection-Pooling an. Echte Performance-Messung geht halt nur mit MS-Stress. > > Es gibt aber einen gravierenden "Nachteil": > > > > Pro SQL-Statement darf es nur eine externe Verbindung geben. Ganz > > normale JOINS m�ssten also in der Originaldatenbank erstellt werden. > > Also Essig mit "alle Views/Procedures in einer separaten > > Datenbank". :-( > > Wieso? Es gibt doch nur eine externe Verbindung... Alles Joins lassen > sich also �ber die interne zusammen mit der einen externen Verbindung > l�sen... Steht so auch in der MSDN. Ich habe zwei Views nach dem Standard-Muster "SELECT * FROM ... IN ...". Wenn ich jetzt diese beiden Views mit JOIN verkn�pfe gibt es einfach einen Syntax-Error. Laut Dokumentation max. 1 "FROM ... IN ..." pro Statement. Dabei hatte mein Statement selber �berhaupt kein "FROM ... IN ...". ;-) > > Wenn man aber z. B. Datenbanken bei einem Provider abgleichen > > will, kann > > man das sehr wohl mit verkn�pften Tabellen machen, also z. B. > > alle neuen > > Daten in eine separate Datenbank kopieren, diese downloaden, > > verarbeiten, wieder uploaden, ... > > > > Du meinst um dem Problem zu entgehen, dass man korrupte DBs runterl�dt? Grunds�tzlich ist es bl�d, wenn man die Datenbank komplett herunterladen muss, um �nderungen vorzunehmen oder diese Daten in anderen Anwendungen zu verwursteln. Einerseits st�ren bei gro�en Datenmengen die Down- und Uploadzeiten, andererseits kann man die Datenbank nicht mehr einfach wieder uploaden, ohne die �nderungen, die in der Zwischenzeit erfolgt sind, platt zu machen. Wenn so etwas laufend erforderlich ist, nehme ich von vornherein den SQL Server, weil ich mich einfach dagegen wehre, solche "simplen" Tools selber zu entwickeln. Bei SQL-Server im Web reicht ein simples MSI- oder SQL-Script, um �nderungen in der Datenstruktur oder in den Daten vorzunehmen. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
