Login
Newsletter
Werbung

Thema: Pro-Linux: Interview mit den Tine 2.0-Entwicklern

26 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Rübezahl am Mo, 18. Februar 2008 um 00:52 #
Danke für das Interview. Immer interessant in die Kochtöpfe andere Köche zu gucken. Ich gehe mal davon aus, das Kommentare erlaubt und erwünscht waren...


Lars: "Als MySQL-Engine verwenden wir ausschließlich InnoDB. Es funktioniert zwar auch mit MyISAM, aber dieses Backend unterstützt keine Transaktionen."

Nun ich sags mal ganz trocken: Mit PostgreSQL hätte es keine entweder-oder-Entscheidungen gegeben. Man bekommt einfach was man bracht. Erinnert mich immer an Drucker-Kauf wo man das Druckerkabel immer noch extra kaufen muss...

Cornelius: "[...]Benutzer berichten beispielsweise immer wieder von verlorenen Verknüpfungen. Da sind dann zum Beispiel Notizen zu einem Telefonanruf in der Datenbank, und keiner weiß mehr, mit wem das Telefonat geführt wurde. Diese Fehler kann man kaum finden, da es in diesen Bereichen kein History-Logging gibt."

Tja, wenn man Fremtschlüssel benutzen würde, würde eine misslungene Aktion wieder aufgerollt werden, eine Ausname werfen und kein Müll zurück lassen.

CREATE TABLE tel_note
(
id SERIAL PRIMARY KEY,
tel_id INTEGER REFERENCES tel_nr (id) NOT NULL,
mitarbeiter_id INTEGER REFERENCES mitarbeiter (id) NOT NULL,
zeitstempel TIMESTAMP NOT NULL,
titel TEXT NOT NULL,
kommentar TEXT NOT NULL
);


Mir scheint, so wir die DB als Backend benutzt wird, hättet man genauso gut eine Text-Datei benutzen können. Aber in einem so frühen Stadium kann man ja vielleicht noch Design-Fehler ausbügeln. Oder die 2.0 überspringen und gleich mit der 3.0 anfangen. :-)

[
| Versenden | Drucken ]
  • 0
    Von ja am Mo, 18. Februar 2008 um 01:04 #
    Ich verstehe auch nicht, warum staendig MySQL verwendet wird. Postgres ist (mittlerweile (es war auch mal anders)) in wirklich jeder Hinsicht besser.
    [
    | Versenden | Drucken ]
    • 0
      Von Peter am Mo, 18. Februar 2008 um 02:30 #
      Schwachsinn, zeig mir mal einen objektiven Test nachdem Postgres schneller ist als MySQL.
      [
      | Versenden | Drucken ]
      • 0
        Von Joe Dalton am Mo, 18. Februar 2008 um 02:53 #
        Der Geschwindigkeitstest würde mich auch interessieren.

        Ansonsten kann ich die Erfahrungen mit Postqre bestätigen. Ich würde vielleicht niocht sagen, dass es in jeder Hinsicht besser ist, aber mindestens vergleichbar.

        [
        | Versenden | Drucken ]
        0
        Von dimitri am Mo, 18. Februar 2008 um 07:30 #
        Ich denke mal, es ist nicht ganz leicht eine etwas bessere Dateiverwaltung mit SQL Abfragesprache mit einer richtigen DB zu vergleichen.
        Allein schon der Schrott mit den verschiedenen Engines. Wirklich vergleichen kann man sowieso nur InnoDB oder falls vorhanden andere Engines die wirkliches Transaktionsverhalten bieten. Alles andere ist als ob ich ein Auto ohne Airbag, ABS und Gurte auf den Markt bring und mich dann ganz stolz hinstelle weil es 5 kg leichter ist.

        Von Triggern, Lockingverhalten und SPs will ich gar nicht anfangen zu reden.
        Die Doku find ich von MySQL allerdings etwas besser (bzw. umfangreicher) als die von PSQL.

        Dim

        [
        | Versenden | Drucken ]
        • 0
          Von Christian am Mo, 18. Februar 2008 um 09:06 #
          Wobei ich ein konsequentes Verwenden von Fremdschlüsseln und die Transaktionsfähigkeit als primär wichtig ansehen würde!
          Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler! Wozu gibt es denn odbc? Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS, aber ich unterstütze eben "alles"! Damit steigen doch die Chacen eines Einsatzes enorm, da man nicht zum Einsatz eines neuen DBMS gewzungen wird, sondern ggf. ein bereits laufendes auch für diesen Taks verwenden kann. (Oder eben eines, mit dessen Wartung man sich gut auskennt!)
          [
          | Versenden | Drucken ]
          • 0
            Von dimitri am Mo, 18. Februar 2008 um 11:19 #
            *gg* Ich erlaub mir mal ein kleines lächeln, da Du wohl noch nie eine größere Anwendung auf zwei Datenbanken lauffähig gehalten hast.
            Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler!

            Genau diese Einstellung führt dann erst zu den richtig groben Schnitzern. Dann wird nämlich begonnen Datenbankverhalten in der Anwendung nachzustricken. Ebay mag das mit viel Erfahrung und Manpower hinbekommen haben, aber Ottonormalprogrammierer scheitert damit immer kläglich sobald es sich um Multiuserumgebungen handelt.

            Der einzige Weg eine Anwendung wirklich performant auf mehreren Plattformen laufen zu lassen, ist die Verwendung von Stored Procedures/Functions in denen die DB abhängigen Teile gekapselt werden. Wir haben zusätzlich noch einen Konverter geschrieben, der Oracle SQL nach Sybase SQLs konvertierte (gab da ein paar kleine aber feine Unterschiede).

            Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS

            Ja eine einfache Adressverwaltung o.ä. könnte damit sogar laufen. Aber spätestens beim Locking musst Du die Unterschiede berücksichtigen. Aber wenn man mit dem Funktionsumfang einer sqlite zurecht kommt, dann kann man auch mit ODBC zugreifen.

            Dim

            [
            | Versenden | Drucken ]
            • 0
              Von nico am Mo, 18. Februar 2008 um 15:01 #
              odbc ist doch nur die verbindung zur db und wirklich etwas feines. In Einzelfällen und wenn es auf Performance ankommt kann man auch spezielle Bibliotheken einsetzen. Kauft sich dann aber wieder Probleme mit Versionsabhängigkeiten ein.

              Aber mit den Rest stimm ich dir voll zu. View, gespeicherte Prozeduren, ... da gibt es eine Menge Funktionalität die man in die Datenbank rein packen kann und so sehr schnell schwierig wird auf ein anderes Datenbanksystem zu übertragen.

              Selbst wenn man auf die ganzen feinen Spielsachen verzichtet kann man durch unterschiedliche Datentypen. Unterschiedlichen SQL-Dialekten und mangelhafter Unterstützung der Standards wie SQL99 ganz schnell schiffbruch erleiden. Selbst wenn es gleiche Ausdürcke in 2 verschiedenen Datenbanksystemen gibt, muss es noch lange nicht das selbe bewirken.

              [
              | Versenden | Drucken ]
              • 0
                Von robert am Mo, 18. Februar 2008 um 22:10 #
                > odbc ist doch nur die verbindung zur db und wirklich etwas feines

                Für Windows und Microsoft Access User vielleicht [/ironie]

                [
                | Versenden | Drucken ]
        0
        Von phs am Mo, 18. Februar 2008 um 17:08 #
        Objektiv ist immer Auslegungssache. Dies ist aber ganz interessant:

        http://tweakers.net/reviews/657/6

        Grüße Philip

        [
        | Versenden | Drucken ]
      0
      Von Penta am Mo, 18. Februar 2008 um 08:02 #
      PostgreSQL ist bestimmt nicht schlecht aber um ein vielfaches weniger verbreitet als MySQL.
      Wenn ich also nur PostgreSQL verwende dann ist die Wahrscheinlichkeit viel geringer daß es jemand verwenden kann.
      Allerdings wurden deswegen Datenbankabstraktionsschichten eingeführt um sich solche immer wieder kehrenden Gedanken sparen zu können. Aber die werden schon wissen was sie tun.
      [
      | Versenden | Drucken ]
      • 0
        Von Christopher Bratusek am Mo, 18. Februar 2008 um 09:49 #
        >> Wenn ich also nur PostgreSQL verwende dann ist die Wahrscheinlichkeit viel geringer daß es jemand verwenden kann.

        Quatsch. PostgreSQL gibt's als binary für Windows, fast jede BSD und Linux Distro bringt es mit. Die Verfügbarkeit ist das geringste Problem. Server-Distros sowieso.

        [
        | Versenden | Drucken ]
        • 0
          Von Rübezahl am Mo, 18. Februar 2008 um 12:16 #
          Alleine schon wegen der Lizenz-Politik würde ich MySQL mit der Kneifzange nicht anfassen wollen. Zu Erinnerung:
          http://www.golem.de/0610/48593.html
          http://blog.koehntopp.de/archives/206_MySQL_und_die_Lizenzen.html
          [
          | Versenden | Drucken ]
    0
    Von Lars Kneschke (Tine 2.0 Core E am Mo, 18. Februar 2008 um 13:35 #
    Diese Designfehler liegen in der langen Historie von eGroupWare begründet. Das heißt natürlich nicht das wir sie wiederholen wollen. Allerdings sind die Probleme in der Realität immer etwas komplexer als sie auf den ersten Blick erscheinen mögen.

    Ein paar Anmerkungen zum Thema PostgreSQL vs. MySQL.

    Wir selbst setzen zu 100% auf MySQL und haben sehr gute Verbindungen zu MySQL. Unsere Kunden setzen ebenfalls zu 98% auf MySQL. So lange das so bleibt, macht es ökonomisch für uns keinen Sinn PostgreSQL zu unterstützen.

    Software wirklich auf 2 verschiedenen Datenbanken optimal zu unterstützen ist extrem aufwändig. Da uns momentan das PostgreSQL KnowHow fehlt, lassen wir es lieber ganz. Ein nicht 100% funktionierendes Datenbankbackend macht keinen Sinn. Da wir aber konsequent auf die Datenbankabstraktion des Zend Frameworks aufsetzen ist jederzeit möglich Support für PostgreSQL zu einem späteren Zeitpunkt zu implementieren. Wir haben das noch nicht getestet, aber vielleicht läuft PostgreSQL ja vielleicht auch ohne Anpassungen schon zum jetzigen Zeitpunkt.

    [
    | Versenden | Drucken ]
    • 0
      Von Rübezahl am Mo, 18. Februar 2008 um 13:52 #
      "Unsere Kunden setzen ebenfalls zu 98% auf MySQL"

      Die Frage ist: Was ist Ursache und was ist Wirkung?!

      Wenn ihr auf PostgreSQL setzen würdet und alle Register ziehen, dann währen alle eure Kunden PostgreSQL-User. Es bliebe ihnen garnichts anderes übrig. Also kann man das Argument locker umdrehen.

      Aus Benutzersicht könnte man auch sagen: Mhhh, sie benutzen MySQL.
      Es gibt keine freie Engine die Volltextsuche _UND_ Fremtschlüssel unterstützt. Das sieht nicht Professionell aus. Da lassen wir lieber die Finger von.

      Aber wenn es euch ein Trost ist: Als ich mir das Tabellen-Modell von SugarCRM angesehen habe, hab ich mich auch kaputt gelacht. So, nach 10 Min. hab ich wieder Luft gekriegt um weiter arbeiten zu können. SugarCRM ist für mich keine Option. Die haben bestimmt auch Kunden die zu 99,999~ % MySQL einsetzen. Ja gut, sollen sie mal...

      [
      | Versenden | Drucken ]
      • 0
        Von Lars Kneschke (Tine 2.0 Core E am Mo, 18. Februar 2008 um 14:07 #
        Wir sind die Ursache und erzeugen Wirkung! :-)

        Es ist total sinnlos über die bessere Datenbank zu philosophieren. Sowohl MySQL als auch PostgreSQL haben Stärken und Schwächen. Orcale und MSSQL übrigens auch. Entscheidend ist was Du aus den Stärken der einzelnen Datenbank machst.

        [
        | Versenden | Drucken ]
        • 0
          Von Rübezahl am Mo, 18. Februar 2008 um 20:31 #
          ...Und, wie wollt ihr jetzt euer Problem mit den korrumpierten Daten in den Griff bekommen?
          [
          | Versenden | Drucken ]
0
Von Tine 2.0 am Mo, 18. Februar 2008 um 01:33 #
War Tine nicht dieses rosa Wohnungseinrichtungsschweinchen? 2.0 = die satanische Version davon?
[
| Versenden | Drucken ]
  • 0
    Von Graf Rotz am Mo, 18. Februar 2008 um 06:01 #
    vorher: http://tinyurl.com/2tl7s4
    hinterher: http://tinyurl.com/yp25fb
    [
    | Versenden | Drucken ]
0
Von Joe Dalton am Mo, 18. Februar 2008 um 03:03 #
Projekte wie der Kernel oder GNOME haben doch erfolgreich gezeigt, dass es auch in kleineren Schritten geht

Der Kernel hat mit dem Sprung von 2.4 auf 2.6 schon einen Revolution statt einer Evolution hingelegt. Und Gnome hat doch auch nicht bei 2.x angefangen.

Verschiedene Webserver, unterschiedliche PHP-Versionen, unterschiedliche Datenbanken und da auch unterschiedliche Versionen. Das ist bei JavaScript also auch nichts Besonders, nur redet in diesem Fall jeder darüber.

Kompatibilitätsprobleme auf einem Server betreffen weniger Personen als auf einem Client. Ich würde mir wünschen, daß lynx trotzdem als Client genutzt werden kann, weil es manchmal keine Alternative gibt aufgrund fehlender XServer-Installation.

Weiterhin gutes gelingen!

[
| Versenden | Drucken ]
0
Von Die alte Leier am Di, 19. Februar 2008 um 14:11 #
Also ich habe eGroupware 1.4 unter postgresql laufen, allerdings nur Probleme.

Was ich trotz allem am meisten vermisse, ist Unterstützung für Groupdav, denn die Anbindung über xmlrpc an Kontact ist, gelinde gesagt, lausig. Keine Ahnung, wie und ob evolution angebunden werden kann.
So werden z.B. Wiederderholungen nicht angezeigt - allerdings verliert auch egw diese gerne mal. Kann aber auch am postgres Backend liegen. Die Einbidung eines simplen LDAP Adressbuches war mir auch ein Rätsel. Einfach nur ein Adressbuch, ohne Benutzerdaten.

Ansonsten wurde Citadel bei den durchaus leistungsfähigen freien Lösungen vergessen, auch wenn es u.U einen etwas anderen Schwerpunkt hat. Leider hat citadel keine eMail Benachrichtigung bei anstehenden Terminen und zwingt einem auch alle seine Räume in den Mailordner, was leider ein KO Kriterium ist.

An Performance dürfte citadel momentan unünertroffen sein, leider ist Webcit optisch voll Misslungen und man merkt doch schnell die konzeptionellen "Schwächen".

[
| Versenden | Drucken ]
  • 0
    Von grefabu am Di, 19. Februar 2008 um 16:17 #
    Tja, ich konnektiere meine 1.4rer mit Kontakt über GroupDAV, geht gut,... jedenfalls bei den Kalendereinträgen. Die Adressen laufen besser über xmlrpc.

    Aber bis alles wirklich rund läuft, wird wohl noch ein wenig Zeit vergehen,...

    Grüße

    [
    | Versenden | Drucken ]
0
Von js am Di, 19. Februar 2008 um 16:56 #
Benutzeroberfläche von Tine 2.0 komplett in JavaScript realisiert. Für einen Außenseiter ist es schwer vorstellbar, dass man damit eine professionelle Anwendung erreichen kann
hjb wie immer mit seinem üblichen JavaScript phobie geblubber...
[
| Versenden | Drucken ]
0
Von Lupus am Di, 26. Februar 2008 um 15:47 #
Hallo an die Deutsche-Liste:

es gab gerade eine Adimin-Entscheidung bezüglich eGroupWare und Tine,
sie ist im Orginaltext unten enthalten - hier die Übersetzung ins Deutsche.

Gruß Birgit

Miles Lott schrieb:
Da Tine die Presse-Klausel des Admin-Statements vom Dezember nunmehr
zweimal verletzt hat, haben wir entschieden Gegen-Maßnahmen zu
ergreifen. Dies wurde getan, nach privater Disskussion mit Lars und Conny:

1. Von nun an, ist Tine nicht länger ein Teil des eGroupWare Projekts.
Sie haben 1 Woche von heute an Zeit ihr svn umzuziehen.

2. Die beiden eGroupWare Entwickler und Projekt-Mitglieder Lars Kneschke
und Cornelius Weiss sind hiermit vom Projekt ausgeschlossen, da sie
mehrfach gegen das Projekt agierten. Sie wurden gewarnt und scheinen
weder Reue zu zeigen noch Respekt für die Regeln des Projektes zu haben.

Die Admins - Ralf Becker, Miles Lott, Pim Snel

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung