5
SQL vs. Filemaker
Guten Abend!
Ich habe heute mal eine etwas anspruchsvollere Frage und hoffe, dass ich hier von ein paar Erfahrungswerten profitieren kann (und in der Folge die richtige Entscheidung treffen werde).
Zurzeit setzten wir für unsere CRM-Software u.a. den MS SQL Server 2008 als Datenbanksystem ein. Ich selbst bin mit dem SQL-Server sehr zufrieden. Nun steht in unserem Unternehmen gerade eine wichtige Entscheidung an, nämlich die Anschaffung einer neuen Warenwirtschaft / ERP-System. Wünschenswert wäre auch hier ein SQL-Datenbanksystem. Ob dies letztlich MS, Postgre, 4D usw. ist, wäre zunächst zweitrangig. Von Entwicklungsumgebungen wie .net, 4D oder eben Filemaker verstehe ich nicht viel. 4D setzt als Entwicklungsumgebung auch auf einer SQL-Datenbank auf, Filemaker nicht.
Wir hatten uns praktisch schon für eine Solution entschieden, als mir nun ein bekannter Admin dringend von der Solution abgeraten hat, weil diese Filemaker als Datenbanksystem und Entwicklungsumgebung einsetzt.
Seine Hauptargumente waren:
- In Filemaker entwickelte Solutions kompilieren keinen echten Quellcode, sondern setzten in erster Linie Makros ein.
- Filemaker ist keine echte Client/Serverlösung sondern Workgroup orientiert. Dies könne erhebliche Probleme im Netzwerk verursachen.
- Es gibt kein Transaktionsmanagement bzw. Logdateien
- Felder, Ansichten, Makros/Scripte und die Daten werden alle in einer einzigen Datei gespeichert, statt hier eine sinnvolle Trennung vorzunehmen (Dem ist auch so!)
- er hat selbst viele Jahre mit Filemaker gearbeitet und findet das Produkt sehr gut, um damit schnell und unkompliziert kleine Datenbanklösungen zu "programmieren". Im größeren Stil - wie z.B. für eine Warenwirtschaft - würde er Filemaker allerdings nicht einsetzen, da hier entwickelte Anwendungen bei größeren Datenmengen zu langsam seien. Nach seinen Aussagen sind keine 5% der Filemakerkunden echte Entwickler. Sondern das Produkt ist in der Hauptsache für den Endverbraucher entwickelt worden, der eben selbst Anwendungen erstellen möchte (z.B. eine Adressdatenbank), ohne komplexe Programmierkenntnisse besitzen zu müssen.
Nun sind wir natürlich sehr verunsichert. Den Anbieter selbst habe ich noch nicht mit den Argumenten konfrontiert. Dies steht morgen an. Allerdings wird das nicht viel bringen, denn er wird mir kaum recht geben -
Bei der ERP-Solution handelt es sich - zumindest kostentechnisch - nicht um kleine Bürolösung, sondern wird uns schlappe 20.000 Euro kosten.
Was sagt ihr?
Greetz
Raphael
Ich habe heute mal eine etwas anspruchsvollere Frage und hoffe, dass ich hier von ein paar Erfahrungswerten profitieren kann (und in der Folge die richtige Entscheidung treffen werde).
Zurzeit setzten wir für unsere CRM-Software u.a. den MS SQL Server 2008 als Datenbanksystem ein. Ich selbst bin mit dem SQL-Server sehr zufrieden. Nun steht in unserem Unternehmen gerade eine wichtige Entscheidung an, nämlich die Anschaffung einer neuen Warenwirtschaft / ERP-System. Wünschenswert wäre auch hier ein SQL-Datenbanksystem. Ob dies letztlich MS, Postgre, 4D usw. ist, wäre zunächst zweitrangig. Von Entwicklungsumgebungen wie .net, 4D oder eben Filemaker verstehe ich nicht viel. 4D setzt als Entwicklungsumgebung auch auf einer SQL-Datenbank auf, Filemaker nicht.
Wir hatten uns praktisch schon für eine Solution entschieden, als mir nun ein bekannter Admin dringend von der Solution abgeraten hat, weil diese Filemaker als Datenbanksystem und Entwicklungsumgebung einsetzt.
Seine Hauptargumente waren:
- In Filemaker entwickelte Solutions kompilieren keinen echten Quellcode, sondern setzten in erster Linie Makros ein.
- Filemaker ist keine echte Client/Serverlösung sondern Workgroup orientiert. Dies könne erhebliche Probleme im Netzwerk verursachen.
- Es gibt kein Transaktionsmanagement bzw. Logdateien
- Felder, Ansichten, Makros/Scripte und die Daten werden alle in einer einzigen Datei gespeichert, statt hier eine sinnvolle Trennung vorzunehmen (Dem ist auch so!)
- er hat selbst viele Jahre mit Filemaker gearbeitet und findet das Produkt sehr gut, um damit schnell und unkompliziert kleine Datenbanklösungen zu "programmieren". Im größeren Stil - wie z.B. für eine Warenwirtschaft - würde er Filemaker allerdings nicht einsetzen, da hier entwickelte Anwendungen bei größeren Datenmengen zu langsam seien. Nach seinen Aussagen sind keine 5% der Filemakerkunden echte Entwickler. Sondern das Produkt ist in der Hauptsache für den Endverbraucher entwickelt worden, der eben selbst Anwendungen erstellen möchte (z.B. eine Adressdatenbank), ohne komplexe Programmierkenntnisse besitzen zu müssen.
Nun sind wir natürlich sehr verunsichert. Den Anbieter selbst habe ich noch nicht mit den Argumenten konfrontiert. Dies steht morgen an. Allerdings wird das nicht viel bringen, denn er wird mir kaum recht geben -
Bei der ERP-Solution handelt es sich - zumindest kostentechnisch - nicht um kleine Bürolösung, sondern wird uns schlappe 20.000 Euro kosten.
Was sagt ihr?
Greetz
Raphael
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 142018
Url: https://administrator.de/forum/sql-vs-filemaker-142018.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
5 Kommentare
Neuester Kommentar
es gibt keine Anwendung, die Du nicht in Filemaker nachbilden kannst. Nimmst Du dann einen SQL-Server als Backend, dann kannst Du unbegrenzt Daten performant vorhalten. Die Layoutmöglichkeiten und deren einfache Umsetzung sind in meinen Augen unerreicht. Bist Du ein Datenbankprofi, wirst Du ob der ungewöhnlichen "Programmierung" allerdings eine SQL-PHP-Anwendung vorziehen. Ich habe Angebote über eine Neuentwicklung der von mir betreuten Filemaker-Anwendung eingeholt, da lagen die Angebote zwischen 30-50 TSD EURO (Filemaker) bis 200.000 EURO (MS-SQL). Ich denke mal, ich fuxe mich wieder ein wenig ein (Filemaker 10, bzw.11).
Gruß, Arch Stanton
Gruß, Arch Stanton
Also bei uns läuft ein ERP System auf Filemaker Basis. Und das ganze nicht mit SQL Backend.
Sagen wir es läuft die Geschwindigkeit geht auch noch bei Dateigrößen über 5GB.
Aber ehrlich, so richtig prickelnd ist das Ganze auch nicht. So leicht wie die Filemaker Datenbank abschmiert, nö das ist nicht wirklich lustig.
Was man aber wirklich sagen muss, Filemaker ist für die Möglichkeiten wirklich günstig.
Sagen wir es läuft die Geschwindigkeit geht auch noch bei Dateigrößen über 5GB.
Aber ehrlich, so richtig prickelnd ist das Ganze auch nicht. So leicht wie die Filemaker Datenbank abschmiert, nö das ist nicht wirklich lustig.
Was man aber wirklich sagen muss, Filemaker ist für die Möglichkeiten wirklich günstig.
Man fragt sich "Access oder Filemaker", aber nicht "SQL oder Filemaker".
Die Frage ist dann: "Richtiges RDBMS oder Desktop DBMS"...
Die Frage ist dann: "Richtiges RDBMS oder Desktop DBMS"...
Hi !
Es gibt Datenbankserver, die auch alles in einer Datei speichern, dass muss kein Nachteil sein....
Soweit ich mich aber noch an Filemaker erinnern kann, ist die Anbindung an das SQL Backend über ODBC realisiert und das ist "langsam". Zumindest im Vergleich zu einem direkten Zugriff über einen nativen Client (z.B. unter Windows über eine Client-Dll).
mrtux
Zitat von @Ridecymbal:
- Felder, Ansichten, Makros/Scripte und die Daten werden alle in einer einzigen Datei gespeichert, statt hier eine sinnvolle
Trennung vorzunehmen (Dem ist auch so!)
- Felder, Ansichten, Makros/Scripte und die Daten werden alle in einer einzigen Datei gespeichert, statt hier eine sinnvolle
Trennung vorzunehmen (Dem ist auch so!)
Es gibt Datenbankserver, die auch alles in einer Datei speichern, dass muss kein Nachteil sein....
Soweit ich mich aber noch an Filemaker erinnern kann, ist die Anbindung an das SQL Backend über ODBC realisiert und das ist "langsam". Zumindest im Vergleich zu einem direkten Zugriff über einen nativen Client (z.B. unter Windows über eine Client-Dll).
mrtux
Die aktuelle Filemakerversion ermöglicht wohl die Anbindung an ein SQL Backend via ODBC. Allerdings wird unsere ERP-Solution Herstellerseitig nicht an SQL angebunden sein.
Ride
Ride
