Hallo, > > > > > > 480 gehen auch noch... > > > > > > > > > > *krass* wieviele Nutzer gleichzeitig? Wieviele Tabellen? > > > > > > > > Ist keine Web-Anwendung, sondern 'ne Labordatenbank. Ziemlich > > > > genau 484 > > > > Tabellen, 897 Formulare, ca. 40MB Code. Verwaltet werden in > > > einer der > > > > Tabellen z.B. Meteorologiedaten im 10 Minutenrythmus > > > > (22Werte) seit 1983. Es > > > > sind aber nur 3-5User gleichzeitig Online. > > > > > > > Dann sollte diese Tabelle so ca. 1Mio Eintr�ge haben... > > > Nicht schlecht... > > > Sind Erm�dungs-Erscheinungen der Access-Engine sichtbar? Wie lange > > > dauern z.B. Abfragen? Ist die DB noch vern�nftig �ber die > > > Access-UI benutzbar/administrierbar? > > > > Das Monats- und Jahresweise Abfragen l�uft maximal 'ne halbe > > Minute, ist > > also kein Problem. Bei solchen Datenmengen sind dann > nat�rlich gr��ere > > Inserts und Deletes nicht ganz ohne. Da geht Access dann > > ziemlich schnell in > > die Knie. > > Also ist es doch eigentlich absehbar, dass access nicht mehr > nochmal so viele Jahre durchh�lt... :-( > > Wieso gibt es so viele Tabellen und Formulare? Werden wirklich alle > st�ndig benutzt oder sind das nur lookup-Tabellen mit sich kaum > �ndernden Werten?
Die Tabellen pr�sentieren jeweils ein System oder Komponente. Und die unterscheiden sich in den zu messenden Gr��en. Es gibt zwar Datenmodelle in denen alle Me�werte in einer Tabelle untergebracht sind und die Eigenschaften dann halt aus anderen Tabellen dazugelinkt sind, da� hat bei vielen Me�werten aber ziemliche Laufzeitprobleme gebracht. Darum haben wir's so aufgeteilt und k�nnen da ziemlich schnell r�ber flitzen. Das Problem ist halt nicht, da� einmal aus einem gro�en Topf was gesucht wird, sondern sehr oft. Und da ist es halt ein Unterschied, ob ich 100000mal aus 5000 oder aus 5000000 Datens�tzen suche. Die Formulare sind entstanden, weil mit der damaligen Rechenpower 386/486 30/40/50MHz keine vern�nftigen Zeiten zum Online-Zusammenbauen der Formulare hinzukriegen war. Darum f�r jedes System ein eigenes Formular, welches dann nach dem �ffnnen sp�testens nach 3 Sekunden alle Datens�tze pr�sentiert. Wir brauchen f�r unsere Arbeit nicht nur den selben momentanen Datensatz in der Ansicht, sondern auch die Historie und gleichzeitig auch andere Systeme. Heute w�re das wohl auch m�glich, sowas online zu machen. Vor den Accesslimits von 2GB mache ich mir keine Gedanken. Die Daten sind sowieso in mehrere Datent�pfe aufgeteilt, die von einer Masterdatenbank verwaltet werden. Klappt alles herovragend und geht ab wie Schmitz's Katze. Nur l�schen sollte man keine gr��eren Datenbest�nde. Aber Datenbanken sind ja zum Sammeln und nicht zum L�schen von Daten ;-) > > Der eigentliche Grund warum wir daf�r immer noch Access > > benutzen liegt in > > dem Vorteil von Access direkt in der Tabelle mit .Seek suchen > > zu k�nnen, im > > Gegensatz zu SQL oder Oracle, die nur .FindFirst etc. > > Ja, hab es nochmal gecheckt... MSSQL unterst�tzt tats�chlich > kein seek, > aber m�sste es nicht auch mit filer o.�. sehr schnell gehen... Da wird > doch sicher bei einem serverseitigen cursor auch der Index benutzt... > > > anbieten. Da wir aber > > sehr viel Abfragen machen in denen wir zu einer 1. Tabelle > > aus einer 2. > > Tabelle alle Datens�tze brauchen, deren Datum m�glichst dicht > > an dem der 1. > > liegt, machen wir sowas alles mit .Seek ">=", ... > > > > Mittlerweile haben schon mehrere Softwareh�user aufgegeben. > > Die Anwendungen > > in Ingres und Oracle liegen bei umfangreichen berechnenden > > Abfragen bei > > 30-45 Tagen (optimale Schl�ssel und direkt nach einem > > reorganiseren)! Mit > > Auch wenn man SPs benutzt? > > > Access und .Seek mach ich das in 10-12 Stunden. > > > > mfG - D. L�tje > > > > W�re es ein Ansatz die Daten mit dennen man die Berechnungen macht in > einer selbstentwickelten einfachen DB-Engine - die auf die geforderten > Operationen hin optimiert ist - zu speichern? Da kann man die 10-12h > bestimmt auch noch in Jahren unterschreiten... > Was ist den die maximale Zeit, die die Berechnung dauern darf und im > welchen Jahr wird Access diese Grenze erreichen? > > Claudius > > > | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp mfG - D. L�tje --- \\|||// //|||\\ | | (� �) (.) (.) " ==============oOO==(_)==OOo=============��O===�==O��============== Dieter L�tje, Kernkraftwerk Kr�mmel, Elbuferstr. 82, D-21502 Geesthacht. Tel.: +49 (0)4152 - 15 27 86, Fax: +49 (0)152 - 15 25 17. eMail: [EMAIL PROTECTED] PGP-Key at: idap://certserver.pgp.com or PGP-Fingerprint: C52A 5AEC 91B1 7F84 3BCA F406 43AE 8845 27CC 09BA | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
