Interbase oder mySQL ???

Interbase oder mySQL ??? (13 Beiträge, 6 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Mehr Seiten hat ja das Interbase-Buch, aber mySQL hat auch was. Schwierig.

Na hoffentlich wird das nicht der nächste AMD-Intel Glaubenskrieg.

Andererseits kann ich mir gut vorstellen, warum hier niemand antwortet: Wer eine der beiden kennt, der kennt die andere mit recht grosser Wahrscheinlichkeit nicht.

Ich find' jetzt natürlich mein schlaues Buch in dem die Unterschiede recht gut aufgezeigt sind nicht. Was mir an mySQL am meisten abgeht sind transactions, trigger und objekts. Wenn Du ohne diese leben kannst (was bei kleineren DBs wie Du sie vorhast durchaus kein Problem darstellen sollte), dann hast Du in mySQL eine sehr schnelle, stabile und verlässliche Datenbank. Ob interbase diese Features bietet weiss ich leider nicht, aus Erfahrung mit Datenbanksystemen, die diese Features bieten kann ich Dir aber versprechen, falls ja hauen sie IRRSINNIG in die Performance der Datenbank, wennst also ohne auskommst, sei froh dass sie nicht da sind.

Shadows can be made real
if you kill in their name.

Im Zusammenhang mit sleepycat's BerkelyDB unterstuetzt MySQL meines Wissens Transactions.
Gruesse,
j.
I can't decide whether to commit suicide or go bowling. -- Florence Henderson More quotes on this site J.

Muss ich mir mal anschauen, für uns wär's langsam interessant. Allerdings bedeuten transactions normalerweise einen ziemlichen performance hit. Hast Du einen Link dorthin zur Hand?

Shadows can be made real
if you kill in their name.

hm.. ehrlich gesagt hab ich davon selbst relativ wenig Ahnung, hab's aber eben ein paar Mal gelesen.
Also...
Hier steht, dass MySQL 4.0 mit dem table handler (? was auch immer das ist..

) Transactions unterstuetzt. (Unter "Other features..")
Hier der Manual-Eintrag fuer InnoDB, hier der fuer Berkeley DB.

Mehr weiss ich leider auch nicht..
HTH,
j.
I can't decide whether to commit suicide or go bowling. -- Florence Henderson More quotes on this site J.

Also, es sieht folgendermassen aus:

Ich möchte einfach ein paar Dinge wie ein Anlagenverzeichnis, ein Arbeitszeit/Kunde-Verwaltungsprogramm mit Rechnungsstellung auf Knopfdruck etc. in einer Datenbank realisieren. Nebenher noch eine Kundenadressenverwaltung usw.

Das komplizierteste und wichtigste ist noch mein Anlagenverzeichnis. Hier sind einige Datenfelder aus dem Inhalt anderer zu berechnen bzw. sind jährlich Werte aus der alten Datenbank oder aus anderen Feldern zu übernehmen (BW 31.12.00 = BW 1.1.01).

Das möchte ich auf möglichst einfache Weise realisieren. Web-Interfaces mittels PHP etc. sind interessant, aber in erster Linie will ich mal nur mein Anlagenverzeichnis.

Bei Transactions, Triggers etc. kenne ich mich nicht aus.

Wie baue ich eine Benutzeroberfläche für mySQL?

Die Datensätze sollten möglichst schön auf Papier gebracht werden können.

Das wär mir auch noch ein Anliegen (ich muss den ganzen Ramsch ja für die Bilanzen ausdrucken).

danke

Fuer viele Sprachen gibt's so APIs fuer MySQL (PHP ist das immer dabei, fuer C und C++ garantiert, fuer Perl sicher auch..).
Ansonsten gibt es myODBC. Damit kann man dann mit jeder Sprache/Anwendung, die ODBC unterstuetzt (z.b. auch mit Access) auf eine MySQL zugreifen. (Dabei gibt's allerdings ein paar kl. Probleme wie z.b. dass ein automat. Zaehler in MySQL einfach ein Feld mit der Eigenschaft AUTO_INC ist, in Access aber ein eigener Typ etc)
Gruesse,
j.
I can't decide whether to commit suicide or go bowling. -- Florence Henderson More quotes on this site J.

mySQL ist nur, ausschliesslich und lediglich der Datenverwalter. Das "back end" der Datenbankanwendung. Dort werden Daten gesammelt, verwaltet, verschoben, vernichtet (allerdings nur auf Zuruf, is' ja ned von MS

), aktualisiert und angelegt.

Mit der Ausgabe, Eingabe und Darstellung derselben hat mySQL herzlich wenig am Hut. Du hast ein Interface, welches SQL Abfragen erwartet und Dir das Ergebnis derselben zurückliefert, mehr nicht. Was Dein Frontend daraus macht ist ein ganz anderes Thema.

Was auf den ersten Blick als Nachteil erscheint ist bei näherer Betrachtung durchaus sehr mächtig. So kannst Du z.B. per PHP, Perl oder was auch immer, und einem Webbrowser Daten eingeben und anzeigen lassen, dazu z.B. ein script auf dem Serverrechner laufen (und über dieses Interface steuern) lassen, das dann einfach nur mehr dafür zuständig ist, den Krempel an einen Drucker zu schicken. Dazu muss dieses script nicht mal sonderlich "schön" sein, weil die "schönen" Teile ja über Browser laufen, die für grafischen Firlefanz sich ja ausgezeichnet eignen.

Shadows can be made real
if you kill in their name.

Wie Fly so schön schreibt: Wer das eine kennt, kennt das andere kaum oder gar nicht.

Was ich nach zwei Monaten intensiven Zusammenlebens mit mySQL weiß, ist nur so viel: Für eine CRM-Datenbank, die es ermöglichen soll die Aufgaben eines Customer Care Callcenters (Kundenverwaltung, Einkaufs- und Servicetransaktionen, Trouble Ticketing, Instant Messaging, etc.) sowohl im LAN als auch im WAN zu erledigen, bin ich noch nicht an irgendwelche Grenzen gestossen.

Allerdings habe ich es insofern leicht, als dass mein Frontend eine PHP-Seite ist und die Berichte ausgesprochen spartanisch aussehen dürfen, da sie nur intern benötigt werden.

Jedenfalls: Mit mySQL kann man leben, und es ist sehr einfach Dokumentationen darüber zu finden, wenn man 'ansteht'.

Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird am Ende beides verlieren.

Benjamin Franklin (1706-1790)

Ohne jetzt die Entscheidung noch schwieriger machen zu wollen, aber hast Du schon PostgreSQL in Erwaegung gezogen? Ist mir halt eingefallen, weil es oft mit MySQL in einem Atemzug genannt wird..
Wesentliche Unterschiede zu MySQL: Unterstuetzt mehr Funktionen als MySQL (MySQL hat z.b. soweit ich weiss grosse Teile des SQL-Standards nicht), ist dafuer auch langsamer.
So ca.
Gruesse,
j.
I can't decide whether to commit suicide or go bowling. -- Florence Henderson More quotes on this site J.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung