Ist Filemaker professionell?

[FAESeb]

Hallo erstmal an alle,

um meine Frage besser zu verstehen, hier ein paar Eckdaten:

Ich bin FAE im ersten Lehrjahr, also zereißt mich aufgrund meiner vielleicht unpräzisen Fragestellung nicht in der Luft. Ich lerne in einem winzigen Betrieb, der hauptsächlich mit Systemadministration und wenig mit Programmierung zu tun hat, also muss ich mich um jede Programmierarbeit bemühen. Wir stellen Kunden lediglich kleinere Filemaker-Datenbanken zur Verfügung. Die konnte mein Chef, welcher nicht so auf Programmierung spezialisiert ist, relativ einfach mit Filemaker zusammenklicken. Nun ermöglicht uns eine neue Problemstellung ein größeres Datenbank-Projekt. Ich persönlich lese mich unabhängig davon gerade in das Thema MySQL und PHP rein. Wenn ich mir aber die recht eigene Filemaker-Software anschaue, rollen sich mir die Nägel auf, da ich das Gefühl habe, dass hier nicht so wirklich zwischen front-end u. back-end unterschieden wird. Nun weiß ich, dass man mit Filemaker nichts desto trotz in der Lage ist, auch komplexere Datenbanken zu programmieren. Die Frage ist nur, ob man sich damit nicht vielleicht nur selber Steine in den Weg legt. Der einzige, der in unserer Firma wirklich fit in dem Gebiet ist, hält sich mit seiner Meinung zurück. Ich würde mich natürlich gerne mit etwas vernünftigem beschäftigen. Was haltet ihr denn von Filemaker? Wie könnte ich meinem Chef die eventuellen Vorteile einer Alternative am besten verkaufen.

Vielen Dank, Grüße

[flashpixx]

Wenn Du mal die konkrete Problemstellung schilderst kann man vielleicht mehr sagen.

Filemaker hat z.B. keine Transaktionssicherung, was eigentlich für eine Datenbank von essentieller Bedeutung ist. Außerdem wird hier Datenstruktur und -haltung gemischt. Ich denke für kleine Anwendungen, die standalone laufen sollen, ist Filemaker wie auch Access durchaus eine Lösung. Bei komplexeren Anwendungen würde ich da aber ganz schnell von abraten

[FAESeb]

Wenn Du mal die konkrete Problemstellung schilderst kann man vielleicht mehr sagen.

Filemaker hat z.B. keine Transaktionssicherung, was eigentlich für eine Datenbank von essentieller Bedeutung ist. Außerdem wird hier Datenstruktur und -haltung gemischt. Ich denke für kleine Anwendungen, die standalone laufen sollen, ist Filemaker wie auch Access durchaus eine Lösung. Bei komplexeren Anwendungen würde ich da aber ganz schnell von abraten

Schonmal vielen Dank.

Die grobe konkrete Problemstellung ist folgendermaßen:

Es ist eine Datenbank für Juristen. Grundsätzlich sind in ihr alle relevanten Informationen zu den Mandanten (Kunden, wenn man so will) und zu den Mandaten (also Rechtsstreitigkeiten) abgelegt. Mit diesen Informationen kann man nun weiß der Geier wie viele Aktionen durchführen. Das geht los beim Schreiben vorgefertigter Serienbriefe Briefe an die Mandanten über Stundenabrechnungen, das Ausdrucken Mandatsrelevanter Informationen, Aktenmanagement, selbständige Überprüfung, ob man nicht schon die Gegenseite vertritt und und und. Dann wird es unterschiedliche Masken für Anwälte und Sekretärinnen geben. Die Datenbank wird auf 'nem Server laufen, an den sich die Clients mit Benutzeraccounts und unterschiedlichen Zugriffsrechten anmelden Können. Dann wird es noch Apps für mobile Geräte geben. Das ganze wird mittelfristig auf 100 bis 150 Accounts hinauslaufen. Kann aber auch mehr werden.

Ich brauche aber keine Lösungsvorschläge, denn das würde den Rahmen sprengen. Es geht mir lediglich um Filemaker.

Nochmals Danke.

[flashpixx]

Bei so einem Projekt würde ich nicht auf Filemaker setzen, denn es ist im Moment schwer abzuschätzen welche Datenmengen Du verarbeiten musst. Du brauchst also ggf ein DBMS was sich erweitern lässt z.B. Clusterfähigkeit. Wenn die Datenmenge so groß wird, dass ein einzelner Dienst diese nicht mehr annehmbar handlen kann, dann musst Du eben mehrere Serverdienste haben, die aber auf einen Datenstamm zugreifen. Das muss aber das DBMS unterstützen.

Weiterhin solltest Du Dir überlegen, wie Du die Absicherung auf die Datensätze machst. So etwas gehört primär in die Datenbank, d.h. wenn Benutzer X nicht das Recht hat Datensatz Y zu sehen, dann könnte der Benutzer einen SQL Select auf der Datenbank ausführen und sollte eben den Datensatz nicht sehen (Stichwort Datenschutz).

Weiterhin würde ich mit bei dem Projekt die Gedanken wie Du Inhalte absicherst, d.h. wenn in einem Datensatz etwas geändert wird, darf man das ab einem bestimmten Zeitpunkt noch. Ich kenne das von Gutachten, wenn ein Gutachten verfasst und vom Gutachter unterschrieben wurde, dann darf es nicht mehr verändert werden. D.h. diese Absicherung gehört auch in die Datenbank. Denn wenn Du, wie genannt, unterschiedliche Applikationen hast, die mit der Datenbank arbeiten müssen, dann musst Du sicherstellen, dass die Daten konsistent sind.

Weiterhin würde ich bei so einem Projekt auch darüber nachdenken, ob man Druckerzeugnisse nicht zentralisiert, d.h. einmal am Tag generiert der Server alle Druckerzeugnisse (z.B. nach Feierabend), so dass man eben dafür eine große Maschine hinstellen kann, anstatt jedes Schriftstück einzeln zu drucken (manueller Druck wäre dann nur eine Zusatzoption).

Ich würde hier vor allem erst einmal die domänenspezifischen Dinge überlegen, d.h. welche Rechtsgrundlage muss überhaupt erfüllt werden. Ist ja ähnlich zu Ärzten, dass hier die Daten einen besonderen Schutz genießen. Z.B. kann man auch überlegen ob die Daten via asymmetrischen Verschlüsselungsverfahren in der Datenbank gespeichert werden, nur wenn der User am Rechner einen USB Stick mit seinen persönlichen Keys einsteckt, lassen sich die Daten entschlüsseln. Man müsste dann zwar entweder einen Generalschlüssel dafür haben oder eben jeder User bekommt seinen eigenen Key, den man in die Usertabelle mit übernimmt und jeden Datensatz eben entsprechend oft hinterlegt. Da man zum Verschlüsseln nur den Public Key braucht, ist das auch eine Idee. Ich würde dabei auch nicht alles verschlüsseln, sondern nur die Daten, die einen besonderen Schutz bedürfen. Vorteil dabei, selbst wenn der Rechner gestohlen wird oder jemand eine Lücke in der Anwendung ausnutzt, bekommt er die Daten nicht.

Bearbeitet 17. Januar 2011 von flashpixx

[MartinSt]

Es ist eine Datenbank für Juristen.

Wollt ihr eine Datenbank oder eine komplette Softwarelösung entwickeln? Für welche Juristen, RA, Notare?

Gruß Martin

[Chief Wiggum]

Hmmmm... Anwälte und Notare als Kunden? Viel Spass...

Ich halte den Ansatz für extrem gefährlich. Habt ihr einen programmierenden Anwalt in der Firma?

Ohne saubere (berufs-) rechtliche Beratung sollte man von dem Bereich "Entwicklung Rechtsanwaltssoftware" die Finger lassen. Oder hast du Ahnung vom RVG? Hast du Ahnung von der DONot und den speziellen Anforderungen an die Urkundsrolle, das Verwahrbuch, das Massenbuch etc?

Achso: viel wichtiger als eine Textbausteinverwaltung ist für einen Anwalt eine funktionierende Kalenderfunktion mit Fristenüberwachung / Fristenkontrolle. Verpasste Fristen können sehr böse Folgen haben.

Eine derartige Software einfach nur zusammenzuklicken ist Wahnsinn - ob es nun mit Filemaker oder Access oder OpenOffice Base geschieht ist egal.

[FAESeb]

Wollt ihr eine Datenbank oder eine komplette Softwarelösung entwickeln? Für welche Juristen, RA, Notare?

Gruß Martin

Das ganze geht dann schon in Richtung Softwarelösung, aber direkt auf unsere bestehenden Kunden angepasst. Nicht direkt für den Markt, sondern um unsere Kunden vor den Nachteilen ausgelagerter Fremdanbieter zu bewahren, mit denen wir uns permanent rumschlagen

Habt ihr einen programmierenden Anwalt in der Firma?

Ohne saubere (berufs-) rechtliche Beratung sollte man von dem Bereich "Entwicklung Rechtsanwaltssoftware" die Finger lassen.

Die Entwicklungs- u. Testphase geschieht in direkter Zusammenarbeit mit unseren Kunden.

Um aber nochmal auf mein Anliegen zurückzukommen. Ich möchte meinen Chef vor der Dummheit bewahren, das amateurhaft zu beginnen, um daraus resultierenden Folgen zu vermeiden. Offensichtlich bin ich bei uns aber der einzige, der sich an so einer Herangehensweise stört. Es liegt nun an mir, ihn davon zu überzeugen, dass das eben keine Aufgabe ist, wo man sich mit Filemaker ein paar relationale Datenbanken zusammenklickt und dann so lange scriptet und fummelt, bis es einigermaßen Funktioniert und man Stundenlang damit verbringt, herauszufinden, wie die Entwickler von Filemaker es sich vorgestellt haben, mit verstecktet Häkchen und Drop-Down-Menüs in einer Apple-Mausschubser-Oberfläche, eine vernünftige Anwendung zusammenzuschustern. Soweit, dass ich das erkannt habe, bin ich auch schon. Mir fehlt jedoch das Fachwissen und die Kompetenz das einen noch-mehr-Leihen erkennen zu lassen. Deshalb bin ich dankbar für jedes Argument, das direkt beweist, dass Filemaker für solche komplexen Strukturen ein Klotz am Bein ist. Richtig Hilfreich sind da z.B. solche Beiträge wie von z.B. flashpixx mit der Clusterfähigkeit. Die bringen mich so ein bisschen auf die richtige Spur.

Also Danke für alle Tipps bisher und ich würde mich über weitere Beiträge freuen.

[flashpixx]

Richtig Hilfreich sind da z.B. solche Beiträge wie von z.B. flashpixx mit der Clusterfähigkeit. Die bringen mich so ein bisschen auf die richtige Spur.

Danke erst einmal. Ich denke Du solltest Dich im Moment weniger auf die Technik konzentrieren, sondern viel mehr auf die Domäne / Inhalt. Die zentralen Fragen wären für mich, einmal die genannte rechtliche Basis und zweitens das Datenvolumen (z.B. weiß ich aus den öffentlichen Verwaltungen, dass hier teilweise bis 25 Jahre die Daten vorgehalten werden müssen, d.h. direkter Zugriff muss möglich sein). D.h. aber auch, dass Du eben mit solchen Volumina arbeiten musst, d.h. effiziente Suchstrategien, vor allem weil es ja im Grunde um reine "Textdaten" geht.

Weiterhin wäre eben bei so etwas auch Indizierungsmechanismen notwendig, die zeitgesteuert durch das DBMS durchgeführt werden können. Bei Filemaker wäre eben das nicht möglich.

Ganz großes Thema wäre eben der Datenschutz bzw die Kontrolle. Ich kenne jetzt Filemaker nicht im Detail, aber jedes DBMS wie z.B. mySQL, Postgres, MS SQL, Oracle können Zugriffsrechte bis auf die Felder verwenden.

Ich würde hier eben den domänenspezifischen Punkt ganz hoch ansetzen, denn es müssen klare Vorgaben eingehalten werden, wobei eben eine *Klick*-Lösung sicherlich nicht das wahre ist. Sprich der Ansatz der Planung / Analyse ist essentiell