Re: Access als Frontend für verschiedene DBMS testen

Hallo!

Gernot Adams schrieb:
> "Josef Poetzl" <news@xxxxxxxxxxx> schrieb
>> Die erste Phase meines DBMS-Test ist nun beendet.
>> Ich kenne nun einigermaßen die Besonderheiten der verschiedenen DBSM
>> bezüglich Datentypen in Tabellen.
>> Diese DBMS habe ich mir angesehen: JET, MSSQL, PostgreSQL 8.0, MySQL
>> 5.0, MaxDB, Firebird, Sybase, Informix und Oracle 10g.
>>
>> Mein persönliche Reihung bezüglich "Access-FE-Tauglichkeit"
>
> vielleicht hab ich Deine Übersicht ja falsch verstanden, aber was ist nun
> für Dich das maßgebliche Kriterium, nach dem Du bewertest, ob ein bestimmtes
> RDBMS "besser" als Backend für Access geeignet ist?

Ich betrachtete bisher die Datenzugriffmöglichkeiten:
a) verknüpfte Tabelle
b) an DAO-Recordset gebundenes Formular
c) an ADO-Recordset gebundenes Formular

Ungebundene Formulare mit Recordsetzugriff per VBA habe ich nicht
genauer betrachtet, da dies immer möglich ist.

Weiters sah ich mir den Tabellenaufbau an. - Wie gut werden die
Datentypen im FE erkannt? - Gibt es Probleme mit bestimmten
Datentypen? - In dieser Betrachtung ist gar nicht da DBMS, sondern die
vorhandenen ODBC- bzw. OLEDB-Treiber ausschlaggebend.

Für die Reihung habe ich kein Bewertungsschema mit Punktevergabe (das
war mir zu aufwendig) o.ä. gemacht, sondern ich stufte nach meiner
persönlichen Einschätzung ein. Daher gibt es auch für jedes beurteilte
DBMS eine kurze "Mängelbeschreibung".
Und für jene die selbst testen wollen, stelle ich meine mdb zum
Download bereit. ;-)

Ergänzend:
MSSQL vs. MySQL
+ MSSQL: verknüpfte Tabelle zeigt die selben Datentypen als eine
JET-Tabelle
- MySQL: Tinyint(1) wird als Integer in der verknüpften Tabelle
angezeigt. - Gibt man einen Wert >255 ein, so wird man erst beim
Aktualisieren des DS und nicht schon beim Verlassen des Feldes darauf
aufmerksam gemacht.

Warum ich PostgreSQL vor MySQL stellte:
Der MySQL-ODBC-Treiber macht je nach Version immer wieder Probleme mit
Access. Bei PostgreSQL ist mir so etwas noch nicht aufgefallen. Aus
diesem Grund erwarte ich mir bei der Verwendung von Postgres weniger
Probleme als mit MySQL.
Da Postgres auch im Hintergrund (stored procedures, views) mehr
Flexibilität bietet, würde *ich* eher Postgres als MySQL (bei freien
DBMS-Wahl) bevorzugen.

Ich will aber gar nicht genauer auf die DBMS-Features eingehen,
sondern beim Zusammenspiel mit einem Access-FE bleiben.
Mit meinem Test wollte ich herausfinden, wie "leicht" von einem
Backend auf ein anders umgestiegen werden kann. Aus diesem Grund habe
ich eine Jet-Tabelle als Basis genommen und dieses in die
verschiedenen DBMS transferiert.

@Gernot:
Wie sehen Deine Erfahrungen mit MySQL als BE für ein Access-FE aus?

mfg
Josef

--
EPT: (Access Error Prevention Table) http://access.joposol.com/
FAQ: (Access-FAQ von Karl Donaubauer) http://www.donkarl.com/
.

Relevant Pages

  • Re: Puby 1.0 Release!
    ... > OSs could be Unix, Linux, os X or any other variant of BSD ... > DBMS could be PostgreSQL or MySQL ... ...
    (comp.lang.ruby)
  • Re: Should I use LISP for this?
    ... Check out MySQL. ... MySQL is actually a pretty bad example of an SQL DBMS. ... There are a number of other open-source SQL DBMSes, ... PostgreSQL is the best-known, and CL-SQL ...
    (comp.lang.lisp)
  • Re: SQL Questions -> migrating MySQL to PostgreSQL?
    ... > Postgresql is an excellent dbms and well worth a look. ... Ok, since the discussion is up, I have used MySQL for years, no problem ...
    (freebsd-questions)
  • Re: Effect of MySQL being acquired by Sun Micro
    ... PostgreSQL did, so new developers (who only knew how to boot into ... Windows) picked MySQL. ... I didn't know SQL support was added that late. ...
    (comp.lang.php)
  • Re: Python, xml, databases, ...
    ... I think you want to be clear whether you want a database or not. ... Any machine can run a service (such as MySQL or PostgreSQL), ... both MySQL and PostgreSQL rely on the Cygwin dll. ...
    (comp.lang.python)