Re: SQL Express vs. Jet



Peter Götz wrote:
....
>>>> der SQL Server läuft als separate Instanz.
>>>
>>> ... und (ver)braucht deshalb die entsprechenden Ressourcen,
>>> zusätzlich zur eigentlichen Anwendung.
>>
>> Peter,
>> welche Ressource? RAM oder CPU?
>
> Sowohl als auch, wie eben jedes andere Programm auch.

Peter,
nur meine Versuche zeigen, dass zwar mehr RAM, aber weniger CPU verbraucht
werden.

....
>>> Wieso mit Access?
>>> Die DB ist eine simple *.mdb und die Anwendung greift via Jet-Engine
>>> auf diese *.mdb zu.
>>
>> Der SQL Server greift auf eine simple *.mdf zu:-)
>
> Der SQL-Server erhält erst mal ein entsprechendes SQL-Statement vom
> Client, interpretiert dieses und greift dann auf die entsprechende(n)
> Datei(en) zu.

Genau so erhält die Jet auch einen SQL-String und interpretiert diesen.

>>> Da die Jet-Engine innerhalb der eigentlichen Anwendung läuft, ist
>>> keinerlei Kommunikation zwischen der Anwendung und irgendeinem
>>> DB-System notwendig. Also weniger Ressourcenverbrauch.
>>
>> Ram - ja? CPU auch?
>
> Natürlich produziert der SQL-Server CPU-Last. Die Jet-Engine tut das
> auch, aber eben innerhalb des selben (Client)prozesses. Es ist also
> keine Kommunikation zwischen verschiedenen Prozessen erforderlich.´

Meinst du, dass diese Kommunikation so viel Aufwand erzeugt und dass die
Nutzung der COM-Komponenten aus dotNET effektiver ist. ich bezweifle das.

>
>>
>>>> was mindestens mehr
>>>> Entwicklungsaufwand bedeutet.
>>>
>>> Warum sollten DB-Zugriffe via Jet-Engine mehr Entwicklungsaufwand
>>> bedeuten als Zugriffe auf einen SQL-Server?
>>
>> Stell dir vor, du implementierst dotNET-Funktionen im SQL-Server
>> 2005. Mit Access müsstest du in jedem Programm zusätzliche dll's
>> einbinden.
>
> Ich verstehe nicht so recht, was genau Du damit meinst.

Ich meine nutzereigene Funktionen auf Basis dotNET, die in den SQL-String
eingeschlossen werden können.

> Und warum Access? Kein Access, sondern VB.net, Jet-Provider u. *.mdb.

Der Jet-Provoder kann keine dotNet-Funktionen im SQL-String ausführen.

>> Aber das
>> Thema hängt wirklich stark von der Aufgabenstellung ab. Bei einfchen
>> Anwendungen nur mit Select's wird kein Unterschied sein, aber z.B.
>> beim Notifications wird es schon sehr aufwendig ohne SQL Server 2005.
>
> Welche Notifications?

Benachrichtigung, wenn in der Datenbank Zustände entstehen, die das
Nutzerprogramm wissen muss.

>>> Da nach einer Einzelplatzanwendung gefragt wird, sind keine
>>> Mehrbenutzerkonflikte zu lösen und somit sehe ich nicht, wo mit der
>>> Jet-Engine ein höhere Entwicklungsaufwand zu erwarten wäre.
>>>
>>>> Ich vermute mal, dass selektive Zugriffe durch
>>>> den SQL Server optimaler ausgeführt werden.
>>>
>>> Bei normalen Select-Statements (SQL) liefert die Jet-Engine die
>>> gewünschten Daten deutlich schneller als der SQL-Server.
>>
>> Da zeigen aber meine Tests ein völlig anderes Ergebnis. Ob ich da
>> vielleicht noch einen Fehler habe, kann ich nicht sagen.
>
> Meine SQL-Serverversion von ADOnetDemo ist leider noch nicht ganz
> fertig. Mit ADOnetDemo (Jet-Version) dauert das Einlesen von z.B.
>
> 100.000 Datensätzen
>
> aus einer *.mdb auf einem
>
> Athlon64 3000 mit 1 GB Ram (WinXP)
> < 2,3 Sekunden,
>
> für die gleiche Datenmenge benötigt ADOnetDemo auf einem
>
> Intel P4 1,6 GHz mit 512 MB Ram (Win2k)
> < 5,2 Sekunden.
>
> Deutliche Unterschiede zugunsten vonJet-Engine/*.mdb gegenüber
> SQL-Server stelle ich bei einem Programm zur Messdatenerfassung fest.

Da würde mich mal interessieren, ob die Technologie incl. Daten identisch
sind. Bei mir kommt bei identischen Daten ein Faktor von 150% in der
Zeitdauer der Abfrage mit einer Jet auf mdb gegenüber SQL 2005; alles unter
VS2005 (FW2.0).

> Bis zu 20 Messautomaten/ClientPC liefern Datensätze mit 3 bis 12
> Feldern (nur num.Werte int32 oder Single). Bei evtl. anfallenden
> Wartezeiten zum Schreiben in die DB werden die Daten in einem Puffer
> zwischengespeichert. Bei Jet/*mdb wird dieser Puffer kaum genutzt. Er
> enthält nie mehr als 2 Datensätze. Beim SQL-Server dagegen sammeln
> sich darin sehr schnell immer wieder mal 10 bis 50 Datensätze.

Führst du da ein separates INSERT aus oder nutzt du einen Datenpuffer
(DataSet, DataTable oder DataRow-Array) mit regelmäßigem Update? Welche
Version des Frameworkes vergleichst du?

Peter


.



Relevant Pages

  • CPU ohne Flash, aber mit bootbarem RAM?
    ... Gibt es eine preiswerte kleine CPU ohne Flash, ... RAM, ... z.B. mit irgendeinem seriellen Interface und wo das Programm auch im RAM ...
    (de.sci.electronics)
  • Re: guenstiges Notebook mit 7200er Disk?
    ... Peter Sieker schrieb: ... wenn CPU und RAM längst fertig sind und auf Daten warten. ... Merken tut man es allerdings erst, wenn man von der 7200er wieder auf ...
    (de.comp.sys.notebooks)
  • Re: Alternative zum SnippetCompiler?
    ... Peter Tübben wrote: ... mach es doch mit einem kleinen eigenen Programm, welches den String im Ram ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Zugriff auf Datenbank im Netzwerk
    ... Peter Götz wrote: ... wenn du nur die CPU-Mikrozyklen einer CPU betrachtest, hast du natürlich ... Prozessen auch bei vielen CPU's gegen 0 geht, ...
    (microsoft.public.de.vb.datenbank)
  • Re: forgot the cpu
    ... When you reset the CMOS did you use the pins method and maybe forgot to ... "Those are my principles. ... "peter" wrote: ... Is the CPU properly seated in its socket and the little leaver down?? ...
    (microsoft.public.windowsxp.hardware)