Marko: relationale DB alternativen zu Access ?

Hallo Leute,

für ein größeres Projekt suche ich ein relationales Datenbanksystem, Access wäre geeignet, habe ich auch schon Erfahrung mit, aber ich suche noch nach Alternativen. Es muss ein vollständiges Relationales DBMS sein, deshalb kommt Staroffice allein wohl nicht in Frage. Es wäre schön, wenn es Internetunterstützung bieten würde (erstmal sollen aber nur statische HTML-Seiten erzeugt werden). ODBC fähig wäre gut, nicht so teuer wie Access sollte es sein, aber auch nicht Hyperkompliziert, da ich mich nicht erst ein halbes Jahr anlernen möchte, bis das System läuft.
Wäre vielleicht MySQL in Verbindung mit einer grafischen Oberfläche (vielleicht Starbase aus Staroffice) ein Möglichkeit, oder kann man da die Datenbankstruktur nur per Kommandozeile erstellen ?.
Die Bedienung der fertigen Datenbank muss dann aber Idiotensicher sein.

Alle nur im geringsten hilfreichen Hinweise und Gedanken sind erwünscht

Gruss

Marko

  1. Hallo,

    Du hast mehrere Möglichkeiten.

    Winzigweich - Lösung:

    Nimm dir den M$ SQL Server. Und programmier das ganze mit Access. So kannst leicht abfragen und berichte machen. Aber wenn du von stat. HTML seiten sprichst redest warscheinlich von Abfragen die eine HTML seite generiern. Ist mit VBA kein Problem hab ich auch mal gemacht bis mir das zuviel arbeit wurde :-)

    Non - Winzigweich - Lösung:

    Einen SQL Server deines Vertrauns (wahrscheinlich MySQL)
    Sollte auch gehen das du es mit Access Programmierst, aber wenn nicht machs mit PERL. Der Vorteil wäre bei der MySql DB das du die PerlModule DBI und das msql/mysql perlmodule zu programmierung verwenden könntest. Also nicht den Umweg über ODBC.

    Es kommt drauf an wie du dir das vorstellst. Ob du nur Abfragen und/oder Input aus/in der/die DB übers Web machst, oder ob die DB auch "Redakuell" betreut wird. zb. per Access Frontend.

    Ciao
    Ludwig

    1. Nimm dir den M$ SQL Server. Und programmier das ganze mit Access. So kannst leicht abfragen und berichte machen. Aber wenn du von stat. HTML seiten sprichst redest warscheinlich von Abfragen die eine HTML seite generiern. Ist mit VBA kein Problem hab ich auch mal gemacht bis mir das zuviel arbeit wurde :-)

      Hm, Ja so ungefähr dachte ich, und werd ich wohl dann doch machen.

      Einen SQL Server deines Vertrauns (wahrscheinlich MySQL)
      Sollte auch gehen das du es mit Access Programmierst, aber wenn nicht machs mit PERL. Der Vorteil wäre bei der MySql DB das du die PerlModule DBI und das msql/mysql perlmodule zu programmierung verwenden könntest. Also nicht den Umweg über ODBC.

      »»

      Diese Möglichkeit klingt zwar ganz gut, aber ist das nicht doch viel aufwendiger, und wenn ich ein Access Frontend nehme, brauch ich doch wieder Access, ist es eigentlich schwer eine einmal gemachte Datenbank (keine ganz einfache Struktur, aber nur etwa 2000 Datensätze) irgendwann von Access nach MySql zu portieren ?

      1. ist es eigentlich schwer eine einmal gemachte Datenbank (keine ganz einfache Struktur, aber nur etwa 2000 Datensätze) irgendwann von Access nach MySql zu portieren ?

        Hallo,

        kommt drauf an, wenn du dich an den SQL standard beim Programmieren hälst. Also keine Access interne funktionen der JET datenbank nimmst, sollte es gehen.

        Das Problem ist weniger die Struktur der DB ausser Tabellen und Verknüpfungen hast ja nicht. Das problem sind die Sachen wie Abfragen und Berichte. (Persönlicher Rekord: dynamischer Berichtgenerierer 10 seiten VBA :-))

        Ich würd sagen du machst es gleich mit einem SQL server. Jetzt hast du nur 2000 Datensätze, aber was ist in 1-2 Jahren wenns mal 20000 Datensätze sind.. dürfte theoretisch der Jet DB nichts ausmachen, aber Access ist nun mal nicht der schnellste :-)

        Ciao
        Ludwig

  2. Hallo Marko!

    Mit Access ist das so ne Sache. Du sagst, es waere ein groesseres Projekt, bezieht sich das auf das Projekt im allgemeinen oder auf die Datenmenge im besonderen? Wir hatten vor einem dreiviertel Jahr auch mit einer AccessDB angefangen. Naja, mit den schnuckligen 15000 Datensaetzen war das auch recht annehmbar. Aber jetzt haben wir mehr als 100000 DS drin, und da ist es echt am Krachen. Du meinst, es werden nur statische HTML-Seiten erzeugt, dann kommt es ja auf die Performance nicht weiter an. Bei uns werden sie dynamisch erzeugt (ASP), was man an den Abfragezeiten merkt.

    Bei uns ist die DB downloadbar, um als Datenquelle fuer eine andere Access-Applikation zu dienen. Ich wuerde ja auch gerne was anderes einsetzen, nur man kann nicht von den ganzen Anwendern verlangen, einen richtigen DB-Server bei sich zu installieren. Viele koennen gerade den Computer einschalten und sich einloggen, und Office ist ueberall vorinstalliert.

    Also gibt es da irgendwas zwischen Access und echtem DB-Server, was nicht gross installiert werden muss und wofuer es einen ODBC-Treiber gibt?

    Calocybe

    1. Bei uns ist die DB downloadbar, um als Datenquelle fuer eine andere Access-Applikation zu dienen. Ich wuerde ja auch gerne was anderes einsetzen, nur man kann nicht von den ganzen Anwendern verlangen, einen richtigen DB-Server bei sich zu installieren. Viele koennen gerade den Computer einschalten und sich einloggen, und Office ist ueberall vorinstalliert.

      Also gibt es da irgendwas zwischen Access und echtem DB-Server, was nicht gross installiert werden muss und wofuer es einen ODBC-Treiber gibt?

      Hallo,

      kommt drauf an was die leute damit machen. Nur abfragen machen und sich die daten ansehen, oder daten eingeben?

      Es gibt zb. für Macromedia Director ein xtra mit dem du auf eine SQL DB zugreifen kannst. Der User bräuchte dann nur noch das Shockwave Plugin für den Browser.

      Ciao
      Ludwig

      1. Hallo Ludwig!

        Von Dir hat man in letzter Zeit ja auch nicht mehr viel gelesen, oder kam mir das nur so vor?

        kommt drauf an was die leute damit machen. Nur abfragen machen und sich die daten ansehen, oder daten eingeben?

        Beides. Und loeschen auch.

        Es gibt zb. für Macromedia Director ein xtra mit dem du auf eine SQL DB zugreifen kannst. Der User bräuchte dann nur noch das Shockwave Plugin für den Browser.

        Nee nee, das was da gedownloadet wird, ist eine ganz normale MDB-Datei, die eben nur Daten ohne Frontendschnickschnak enthaelt. Ab dann hat das nichts mehr mit Browser zu tun. Oder kann man das Shockwave-Plugin auch ohne Browser verwenden? Naja, es kommt dann noch dazu, dass mein Broetchengeber nicht gerade die kleinste Firma ist, da kann man nict so einfach durchsetzen, dass die Leute sich die Plugins irgendwo herholen.

        Meine Idealvorstellung ist eine DLL, auf die ich von Access aus zugreifen kann, und die ich mit ein paar SQL-Statements bewerfen kann, und die DLL macht dann die ganze Backend-Arbeit. So eine DLL koennte ich einfach bei dem Frontend mit beilegen, das wuerden die User gar nicht merken. Statt bisher eine MDB als Backend herunterzuladen, waere es dann eben eine andere Datendatei (oder auch mehrere). Wenn ich mir das so ueberlege, kann das doch gar nicht so schwer sein, eine DLL zu schreiben, die einfach gesagt bekommt, welche Datei sie oeffnen soll und dann die SQL-Statements entsprechend umsetzt. Eigentlich koennte ich das auch selber, aber dann waere es wahrscheinlich noch langsam als Access. ;-)

        Calocybe

        1. Nee nee, das was da gedownloadet wird, ist eine ganz normale MDB-Datei, die eben nur Daten ohne Frontendschnickschnak enthaelt. Ab dann hat das nichts mehr mit Browser zu tun. Oder kann man das Shockwave-Plugin auch ohne Browser verwenden? Naja, es kommt dann noch dazu, dass mein Broetchengeber nicht gerade die kleinste Firma ist, da kann man nict so einfach durchsetzen, dass die Leute sich die Plugins irgendwo herholen.

          Meine Idealvorstellung ist eine DLL, auf die ich von Access aus zugreifen kann, und die ich mit ein paar SQL-Statements bewerfen kann, und die DLL macht dann die ganze Backend-Arbeit. So eine DLL koennte ich einfach bei dem Frontend mit beilegen, das wuerden die User gar nicht merken. Statt bisher eine MDB als Backend herunterzuladen, waere es dann eben eine andere Datendatei (oder auch mehrere). Wenn ich mir das so ueberlege, kann das doch gar nicht so schwer sein, eine DLL zu schreiben, die einfach gesagt bekommt, welche Datei sie oeffnen soll und dann die SQL-Statements entsprechend umsetzt. Eigentlich koennte ich das auch selber, aber dann waere es wahrscheinlich noch langsam als Access. ;-)

          Hallo Calocybe,
          ich weiss zwar nicht, was fuer eine Server-DB Du hast (generierst Du die "Versand-DB" aus Access heraus oder aus irgendeiner anderen DB heraus? Wenn Du statt Access auf Deinem Server eine richtige DB hast (z.B.: DB2 oder Oracle) kannst Du ja auch mal bei Big-Blue schauen, ob nicht NET.DATA das Produkt ist, mit dem Du arbeiten kannst. Mit diesem netten schicken "kleinen" Macro-Tool kannst Du ein Web-Frontend fuer Deine Datenbank schreiben, das auch etwas komplexere SQL-Statements beherrscht. Du hast dann die Power des Webs und die Power einer Datenbank im Ruecken. Die Geschichte mit der Access-DB zum runterladen macht mir (wenn ich das hoere) doch unter dem Punkt Daten-Konsistenz und Vergleichbarkeit von Berichten erhebliche Bauchschmerzen. Wenn Deine User natuerlich noch PC-gebundene optische Reports auf der Basis von Datenextrakten haben wollen, kein Problem: mittels des FlatFile-Interfaces schreibst Du den Extrakt auf die Server-Platte, hast zu der Query zum Beispiel ein Excel-Makro zu Download und machst ueber "Auto_Open" einen Datenimport, den Du dann aufbereitest, fertig ist die Kiste (Deine User brauchen dann nur noch Excel-User-Know-How, das etwas teuerere OFFICE-Professional kann evtl. entfallen, Berichte werden vielleicht sogar standartisiert).

          Michael N.

          PS.: Nach zweieinhalb Wochen Urlaub bin ich jetzt wieder Online. Hier in Koeln war ja die letzten zwei Wochen die Hoelle los und da war ich von meinem Hobby aus doch etwas oefter gefragt und hab deswegen Urlaub genommen.

          1. Hi Michael!

            ich weiss zwar nicht, was fuer eine Server-DB Du hast (generierst Du die "Versand-DB" aus Access heraus oder aus irgendeiner anderen DB heraus?

            Es gibt eine Master-DB (Access), in der die Datenpflege vorgenommen wird. Von dort wird ab und zu eine Web-DB generiert, auf die der Webserver zugreift, um die Seiten zu bauen, sowie ein Download-DB. Alles mit Access.

            Die Geschichte mit der Access-DB zum runterladen macht mir (wenn ich das hoere) doch unter dem Punkt Daten-Konsistenz und Vergleichbarkeit von Berichten erhebliche Bauchschmerzen.

            Die wird ja nicht wieder hochgeladen. Die User koennen lokal Ergaenzungen machen, aber das gane ist keine Replikation. (Access bietet zwar irgendsowas an, aber davon lass ich doch lieber die Finger, denn dafuer muesste ich je Vertrauen zu dem Ding haben.)

            Wenn Du statt Access auf Deinem Server eine richtige DB hast (z.B.: DB2 oder Oracle) kannst Du ja auch mal bei Big-Blue schauen, ob nicht NET.DATA das Produkt ist, mit dem Du arbeiten kannst.

            Wer zum Teufel ist Big-Blue? Nee, habe eben keine richtige DB.

            »»  Mit diesem netten schicken "kleinen" Macro-Tool kannst Du ein Web-Frontend fuer Deine Datenbank schreiben, das auch etwas komplexere SQL-Statements beherrscht. Du hast dann die Power des Webs und die Power einer Datenbank im Ruecken.

            Meinst Du damit, es laeuft zentral ein Server auf den ueber's Netz zugegriffen wird? Das ist dann nicht so gut, denn das soll ja auch alles auf einem Laptop laufen. Deshalb der Download der Datendatei.

            Wenn Deine User natuerlich noch PC-gebundene optische Reports auf der Basis von Datenextrakten haben wollen, kein Problem: mittels des FlatFile-Interfaces schreibst Du den Extrakt auf die Server-Platte, hast zu der Query zum Beispiel ein Excel-Makro zu Download und machst ueber "Auto_Open" einen Datenimport, den Du dann aufbereitest, fertig ist die Kiste (Deine User brauchen dann nur noch Excel-User-Know-How, das etwas teuerere OFFICE-Professional kann evtl. entfallen, Berichte werden vielleicht sogar standartisiert).

            Die Reports werden von Access gemacht und haben ein vorgegebenes Aussehen. Allerdings waere eine Loesung ueber Excel nicht ganz schlecht, da die User sich schon manchmal wuenschen, in das Layout eingreifen zu koennen.

            PS.: Nach zweieinhalb Wochen Urlaub bin ich jetzt wieder Online. Hier in Koeln war ja die letzten zwei Wochen die Hoelle los und da war ich von meinem Hobby aus doch etwas oefter gefragt und hab deswegen Urlaub genommen.

            Naja, hier um Forum war's ganz lustig, hatten ne kleine Pause eingelegt, und machen neuerdings immer oefter Threads mit ueber 60 Postings (siehe weiter unten).

            Calocybe

            1. Hallo Calocybe,

              Wenn Du statt Access auf Deinem Server eine richtige DB hast (z.B.: DB2 oder Oracle) kannst Du ja auch mal bei Big-Blue schauen, ob nicht NET.DATA das Produkt ist, mit dem Du arbeiten kannst.

              Wer zum Teufel ist Big-Blue? Nee, habe eben keine richtige DB.

              Big-Blue ist so eine "kleine" ;-) EDV-Schmiede namens IBM, die stellen halt so ein paar "kleine" ;-) Rechner und Software-Produkte her.

              »»  Mit diesem netten schicken "kleinen" Macro-Tool kannst Du ein Web-Frontend fuer Deine Datenbank schreiben, das auch etwas komplexere SQL-Statements beherrscht. Du hast dann die Power des Webs und die Power einer Datenbank im Ruecken.

              Meinst Du damit, es laeuft zentral ein Server auf den ueber's Netz zugegriffen wird? Das ist dann nicht so gut, denn das soll ja auch alles auf einem Laptop laufen. Deshalb der Download der Datendatei.

              Wenn Du mit Netz das WEB (WWW) meinst, dann hat man natuerlich OFFLINE einen schlechten Zugriff, aber ich denke auch dieses Problem wird sich in einigen Jahren erledigen, da es irgendwann sehr sehr billig wird ONLINE zu sein.

              PS.: Nach zweieinhalb Wochen Urlaub bin ich jetzt wieder Online. Hier in Koeln war ja die letzten zwei Wochen die Hoelle los und da war ich von meinem Hobby aus doch etwas oefter gefragt und hab deswegen Urlaub genommen.

              Naja, hier um Forum war's ganz lustig, hatten ne kleine Pause eingelegt, und machen neuerdings immer oefter Threads mit ueber 60 Postings (siehe weiter unten).

              Hab's schon mitgekriegt, dass es hier mal wieder ganz schoen gekocht hat (hast ja sicher auch meine Reaktion auf eines der beliebten ( ;-) ) "Ich will was am Forum geaendert haben"-Postings gesehen (Aber das ist eine ganz andere Diskussion und da habe ich mich wirklich bemueht hoeflich zu bleiben (obwohl ich sowas so kurz nach einer Schliessung ja schon dreist im Quadrat finde).

              Bis dann
              Michael N.

              1. Hallo mal wieder

                Big-Blue ist so eine "kleine" ;-) EDV-Schmiede namens IBM, die stellen halt so ein paar "kleine" ;-) Rechner und Software-Produkte her.

                Ach so, naja, wer kennt die schon? ;-)

                Wenn Du mit Netz das WEB (WWW) meinst, dann hat man natuerlich OFFLINE einen schlechten Zugriff, aber ich denke auch dieses Problem wird sich in einigen Jahren erledigen, da es irgendwann sehr sehr billig wird ONLINE zu sein.

                Es geht da weniger um die Kosten, bei uns ist sowieso jeder die ganze Zeit online, solange er im Buero ist. Es ist nur so, dass die Leute mit dem Tool auf dem Laptop auf irgendeine Anlage (alles von Waschstrasse bis AKW) gehen und dort daran arbeiten. Und dort sieht's dann wirklich oft schlecht aus mit Stoepsel.

                [..] (Aber das ist eine ganz andere Diskussion und da habe ich mich wirklich bemueht hoeflich zu bleiben (obwohl ich sowas so kurz nach einer Schliessung ja schon dreist im Quadrat finde).

                Warst doch auch hoeflich.

                Calocybe

        2. Hallo Ludwig!

          Von Dir hat man in letzter Zeit ja auch nicht mehr viel gelesen, oder kam mir das nur so vor?

          Stimmt, warum soll ich auf was antworten, zu dem schon genung leute die richtige antwort gepostet haben, oder antworten auf sinnlose postings? :-)

          Beides. Und loeschen auch.

          Es gibt zb. für Macromedia Director ein xtra mit dem du auf eine SQL DB zugreifen kannst. Der User bräuchte dann nur noch das Shockwave Plugin für den Browser.

          Nee nee, das was da gedownloadet wird, ist eine ganz normale MDB-Datei, die eben nur Daten ohne Frontendschnickschnak enthaelt. Ab dann hat das nichts mehr mit Browser zu tun. Oder kann man das Shockwave-Plugin auch ohne Browser verwenden? Naja, es kommt dann noch dazu, dass mein Broetchengeber nicht gerade die kleinste Firma ist, da kann man nict so einfach durchsetzen, dass die Leute sich die Plugins irgendwo herholen.

          Ist doch kein Problem (programmier technisch gesehen.)
          wo liegt der unterschied zwischen einer DLL und eines Plugins? Hast du ein Problem damit wenn du per Sockwave auf das db-file zugreifst? Hätt auch den Vorteil das es auf fast jeden Betriebssystem und auf jeden Browser geht der das Plugin hat. Du hast eine Oberfäche mit oder ohne Schnickschnack. Die user können sich abfragen zusammenstellen, daten eingeben, löschen... usw.

          Ciao
          Ludwig

          1. Hi!

            Ist doch kein Problem (programmier technisch gesehen.)
            wo liegt der unterschied zwischen einer DLL und eines Plugins?

            Na dass man das Plugin installieren muss, oder?

            Hast du ein Problem damit wenn du per Sockwave auf das db-file zugreifst?

            Ist vielleicht ein bisschen unkonservativ, aber so prinzipiell koennte ich damit vielleicht sogar durchkommen. Wie ist das eigentlich mit Lizenzkosten, wenn man das gewerblich nutzt? Da bei uns sowieso ueberall Office 97 installiert ist, haben wir da keine Kosten. Aber wenn ich fuer jeden User ne Extra Lizenz braeuchte, waere das so ziemlich das KO-Kriterium.

            Hätt auch den Vorteil das es auf fast jeden Betriebssystem und auf jeden Browser geht der das Plugin hat. Du hast eine Oberfäche mit oder ohne Schnickschnack. Die user können sich abfragen zusammenstellen, daten eingeben, löschen... usw.

            Windows reicht schon. Wie ist das jetzt mit dem Browser. Brauch ich den nur, um das Plugin zu installieren, oder auch dann, um es zu benutzen? Oder kann ich einfach aus Access auf das Ding zugreifen?

            Calocybe

            1. Na dass man das Plugin installieren muss, oder?

              Nicht zwingend, Communicator und IE5 haben es standardmässig drinn.

              Ist vielleicht ein bisschen unkonservativ, aber so prinzipiell koennte ich damit vielleicht sogar durchkommen. Wie ist das eigentlich mit Lizenzkosten, wenn man das gewerblich nutzt? Da bei uns sowieso ueberall Office 97 installiert ist, haben wir da keine Kosten. Aber wenn ich fuer jeden User ne Extra Lizenz braeuchte, waere das so ziemlich das KO-Kriterium.

              Du brauchst mal mind. 1 Lizenz für Director 7. Die Plug-ins sind frei verfügbar.

              Windows reicht schon. Wie ist das jetzt mit dem Browser. Brauch ich den nur, um das Plugin zu installieren, oder auch dann, um es zu benutzen? Oder kann ich einfach aus Access auf das Ding zugreifen?

              Es wird alles Im Browser gemacht.

              Ciao
              Ludwig

              1. Hi Ludwig!

                Es wird alles Im Browser gemacht.

                Mmh, des is net so gut. Duerfte erstens nicht gerade zur Akzeptanz beitragen, ausserdem muss man auch jede Menge Reports rauslassen. Aber gut zu wissen, dass Shockwave sowas ueberhaupt kann. Vielleicht eignet sich es mal bei einem anderen Anwendungsfall.

                Calocybe