Filemaker的优点和缺点是什么？
一位潜在客户要求我查看一些促销传单，以获取联系人pipe理/计划程序类别中的几个应用程序。 两者都使用Filemaker作为后端。 看起来这两个应用程序是作为networking应用程序销售的。 无论如何，我在十年左右都没有听说过Filemaker，所以看到它在同一个场合出现两次，真是令人惊讶。 我认为它开始作为一个Mac平台数据库系统。
我更偏向于SQL Server，MY SQL等，但在对Filemaker做出任何评论之前，我想知道系统的一些优缺点。 它必须不仅仅是Access for Mac，但是我从来没有在客户端/服务器或Web应用程序领域作为玩家来运行它。
非常感谢麦克托马斯
优点：
- 这很便宜
缺点：
- 它很便宜（制造）
- 这是非标准的（很容易findMySQL / Oracle / MSSQL / Access专家，但没有人知道Filemaker）
使用次级和/或非标准技术只会造成技术债务 。 我从来没有find一个实际享受（或想）使用这个利基产品的可敬的开发。
在我看来，这款产品的存在是因为它是Access for Macs，并且获得了足够的用户群和现有的应用程序，足够多的人购买了每个升级版以保持业务。 市场上有很多产品仍然存在，因为它是用户被locking的，而不是因为它是一个不错的select。
调用Filemaker Pro，访问Mac就像是说，Mac OS X是Mac的Windows。 他们都在同一类软件中，他们是集成的编程环境。 这就像你有MySQL，PHP，HTML和你的编辑器放在一个graphics用户界面。 比较两者，都有利弊。 根据我的经验，以下是使用Filemaker Pro vs PHP / MySQL / HTML的优缺点。
优点：
- 容易上手
- 易于本地部署，打开共享和从另一个客户端连接
- 跨平台（Mac OS X，Windows，iOS）
- 有很多插件可用来扩展function
- 包括初学者解决scheme
- 任何有权限的人都可以编辑程序
- 大多数情况下，拖放编程
- 事后免费更改字段/数据库/脚本名称
- 有一些整洁的窍门，如build立在图表，选项卡控件，网页浏览器
- 内置支持导入导出excel，cvs，制表格式
缺点：
- 不灵活：它做得很好，但如果你需要更多的运气，大部分
- 与免费替代品相比，价格昂贵：一个本地用户每年花费大约100美元，每个开发者花费150美元，如果你使用它作为一个网站，你需要专门的托pipe，这往往会花费更多。 另外，该软件的服务器部分每年约为300至800美元
- 扩展function所需的插件也可能很昂贵
- 几乎只有拖放编程，你只能使用预定义的脚本步骤，通过制作一个graphics来进行关系
- 来源控制是问题
- 缺乏可扩展性
- 无法复制和粘贴/导入或导出解决scheme中的某些项目
- 需要鼠标才能访问function
- 布局devise是相当静态和过时（这是改善与Filemaker 12及以上）
一般来说，我会说，如果你正在开发专门的networking或大型组织Filemaker Pro可能不是最合适的。 在同一个解决scheme上开发多个人是很困难的。 另一方面，对于需要定制内部数据库的小型组织来说，这可能是一个很大的好处。 如果你愿意处理它的缺陷，你可以非常快速地构build相当复杂的应用程序。
我承认在这个问题上存在偏见 – 我与其中一个较大的FileMaker开发商合作，并撰写了关于这个主题的奇怪书。 我们实际上雇佣了许多喜欢使用FMP的可敬的开发者。 我会尽量保持简短。 🙂
FileMaker Pro是一个快速的应用程序开发工具。 它主要是客户端服务器，虽然它有一些非常可敬的networking发布function，适用于许多应用程序。 它不是基于SQL的，但有ODBC和JDBC接口，以及XML / HTTP接口。
就locking而言，FileMaker Inc的销售稳步增长，新用户的吸引力也大大增加。
我认为马特·霍顿（Matt Haughton）认为 – 对于正确的应用，FMP是最好的select。 也就是说，您的客户正在查看使用FMP Pro编写的应用程序，您需要根据自己的优势评估这些应用程序。 他们可能是FMP发展的好例子，或者他们可能不是。
要了解更多关于FMP适合这项任务的信息，我们需要了解更多关于build议的应用程序和用户群的信息。 这些确实是Web应用程序，还是客户端服务器？ 有多less用户将使用它？ 他们在一个或两个地点工作，还是分布在互联网上？
如果有更多的兴趣，很乐意进一步阐述。
FileMaker旨在与其他数据库和客户端应用程序进行非常简单的集成。 如果你正在build立一个复杂的分布式系统，请看看其他地方。
由于外部SQL数据源（ESS）function集的devise目标，FileMaker不太适合作为其他数据源的前端，因此不适合作为其他任何FM客户端的后端由于缓慢和错误的ODBC驱动程序。 FileMaker体系结构的本质意味着，不pipe复杂的解决scheme如何与其他系统集成，它都不能很好地扩展。
以下是开发人员对将FileMaker与其他后端和ODBC客户端进行组合时发现的一些限制的看法 ：
- ODBC驱动程序是有限的，速度慢，并在客户端泄漏内存。 xdbc_listender.exe在服务器端有类似的内存泄漏问题，并且在使用一定数量的RAM时最终会崩溃。 我们有一个预定的脚本，每天晚上重新启动它。
- FileMaker需要将所有相关数据库加载到内存中，然后才能连接到数据库。 如果数据库复杂， 打开和closures连接可能会非常缓慢 （1-2秒），具体取决于数据库的结构，如果数据库引用其他FM数据库中的表，还需要加载数据库。 我通过创build在应用程序的整个生命周期中保持打开的持久连接来解决这个问题。 虽然我们尽量减less打开连接的数量，但是我们还没有看到服务器上的性能问题。
- ODBC驱动程序以奇怪的方式解释查询。 例如，我运行一个查询76k行UPDATE table_1 SET field_1 = 1，并花了5分钟来执行查询，因为我认为它将一个查询拆分成46k更新查询，每行一个。 我知道这一点，因为我看着它在FM客户端中逐行更新行。 所以我根本不相信ODBC驱动程序。
下面是3个不同查询的另一个例子，他们在两个date字段上search了多长时间：
SELECT id FROM table WHERE datefield1 = {d '2014-03-26'} 。5秒
SELECT id FROM table WHERE datefield2 = {d '2014-03-26'}
。5秒
SELECT id FROM table WHERE datefield1 = {d '2014-03-26'} OR datefield2 = {d '2014-03-26'}
1分13秒！
- FileMaker如何caching SQL Express数据库中的数据时遇到问题。 我们尝试运行该命令来清除caching，但并不总是有效（花了很多时间来研究这个）。
- FileMaker使用logging的悲观locking ; 在编辑之前（从客户端或作为odbc事务的一部分），FileMaker首先尝试locking行。
- FileMaker Server服务“更喜欢”使用pipe理控制台停止（尽pipepipe理控制台有时可能无法停止）。 如果FileMaker Server服务停止任何其他方式（包括断电，通过pipe理控制台，甚至正常的系统closures），那么您的某些数据库可能会损坏。 在操作过程中客户端崩溃或networking连接突然中断的情况下也是如此。 停电的解决scheme是编写一个批处理脚本来尝试自动closures，然后购买一个UPS并编程，在果汁用完之前执行脚本。 并希望它的作品。 否则使用内置调度程序每小时进行一次备份。 另外：SQL服务器没有这个问题，因为它可以回滚未提交的事务。
- 使用内置调度程序执行备份实际上会在备份过程中暂停对数据库的操作。 即如果它是一个大的数据库，那么可能需要一分钟的时间进行备份，用户会注意到暂停，因为他们不能编辑/插入等。
- 如果您使用的是FileMaker PHP API ，请注意，您不能在同一个请求中同时使用AND和OR。
- 使用ODBC驱动程序运行密集查询可能会很快，但同时运行相同的查询 （如在多用户环境中），并且会以指数forms减慢大约300％。 如果您希望大量的密集查询同时击中数据库，则会遇到速度问题。
- 我们发现当FileMaker ODBC驱动程序说它已经完成更新/插入操作时，它仍然不能保证事务被提交; 看起来FileMaker将继续保持服务器caching中的更改，直到自动input计算字段被评估/索引，然后将其保存到光盘，这意味着直到logging实际提交之前可能会有更多的延迟。 所以真正的ODBC写操作并不总是立即写入，而是最终的写入 。 这种延迟在具有许多计算字段和触发器的复杂表格中尤其明显。
- 计算字段可能会降低执行速度，并通过ODBC驱动程序进行读取 ，具体取决于正在评估的内容。 尝试尽可能读取存储的值。
- 使用BLOB容器 ：不推荐。 将文档（如PDF）存储在容器字段中会使数据库文件大小膨胀，需要较长的时间进行备份，并使通过ODBC检索和编辑这些文件复杂化。 将文件存储在networking共享上并写入磁盘上的文件要容易得多。
如果您必须将FM用作另一个数据库的前端解决scheme，请确保仔细阅读FileMaker的“外部SQL源简介” 。
另请参阅在其网站上find的相应版本的“FileMaker ODBC指南”。
只是对这个问题的一些意见
FileMaker肯定比许多企业解决scheme在许可成本方面要便宜。 但是，真正的成本效益正处于发展时期。 开发生命周期通常低于其他企业平台（无论这些平台的许可成本如何）。 我的意思是日子，而不是几个星期，或者几个星期而不是几个月来开发一些function。
有一个强有力的说法，即FileMaker是Access for Mac。 虽然这是几年前的一个有效论据，但近年来FileMaker已经进入了自己的领域。 值得注意的是，FileMaker是跨平台的，并在Mac和Windows上广泛使用。 话虽如此，FileMaker和Access之间仍然存在着巨大的相似和不同之处，但事实并非如此。
虽然FileMaker是非标准的，但它支持与MySQL，MS SQL Server和Oracle的实时连接。
另外，FileMaker的开发人员也不及更多的标准平台，但他们肯定是关于的，如果你让我知道你在哪里，我可以让你联系你所在地区的开发人员。
我想要说明的重要一点是，在正确的情况下，FileMaker是世界上最好的事情，如果你试图做一些不该做的事情，你将会陷入困境。 但是，它可以支持4个地点的办公室，它可以并正在完成。
在你去其他平台上重写你的系统之前，你应该联系一位FileMaker专家，看看他们现在得到了什么，在这个网站上写更多的细节，让非专家回答正面或负面不会帮助你 最后，它必须是成本与收益的商业select。
没有必要再列出“缺点” – 但这里是一个重要的“专业” – Filemaker去。 完成数据库设置后，下载一个ipad / iphone应用程序（免费用于FM12）并从移动设备上运行。 数据库可以存储在本地ipad / iphone或同步回主机。
我确信这个移动解决scheme在其他地方是可能的，但是最基本的一点是入门级用户（我的意思是没有以前的数据库经验）可以在几个星期内创build一个令人印象深刻的解决scheme。
个人经验：运行FM 11的主数据库在我的办公桌下放置在个人电脑上 – 分散在城市中的4名研究人员收集有关ipad的数据 – 所有数据都同步回到我的电脑。 以前的解决scheme是使用纸张并手动input数据。
FileMaker是一个有趣的应用程序:)它作为一个最终用户工具开始，它仍然是一个非程序员可以实际使用的极less数的数据库应用程序之一。 但不知何故，FileMaker开发人员设法使其具有很强的可扩展性。 没有其他的平台可以从一个有用的工具开始，最终为整个公司提供一个客户端 – 服务器应用程序。 在过去，他们曾经有一个启animation面，捕捉这个想法（我只发现一个不完美的版本）：
就像一个可以长得相当大的文件柜一样简单。
所有FileMaker的优点和缺点都来源于它。 作为最终用户工具，它与其他DBMS应用程序非常不同。 没有SQL。 没有真正的编程：脚本基本上是用variables和逻辑稍微更一般地重复用户操作的macros。 很多限制; 例如列表视图不能有一个侧边栏; dynamic值列表总是按字母顺序sorting; 打开“另存为”对话框并回读文件名称，您将需要一个插件; 等等。 对程序员来说，这可能是非常令人沮丧的，因为他的大部分假设都是错误的。 而由非程序员编写的现有应用程序并不完全是清晰和可靠devise的典范。
但是如果你设法克服障碍，你会发现一个相当不错的客户服务器，单用户，networking和移动应用程序的RAD，在广域网上保持相当的可用性，如运行时和信息亭模式。
话虽如此，我不太清楚FileMaker中的通用联系人pipe理和调度应用程序。 如果是这样，那么他们应该被解锁，所以客户可以做出改变; 或者他们必须是为客户做的没有其他任何事情的利基应用程序。
Filemaker是非常强大和多function的。 优秀的多用户支持。 您可以使用文档pipe理，Web界面，iPhone界面，自动发布支持，预定脚本，PDF / Excel / HTML报告，XML支持，来电显示logging查询，Web数据整合（UPS和Fedex链接到订单logging例如）。 可扩展的插件。 这就像是在数据的家得宝。 不要试图build立亚马逊; 除此之外，你可以用它来创build什么，以及比其他任何地方更快的应用程序开发？
自从我运用FM并用它开发各种客户的解决scheme以来，已经有一年多的时间了。 以下是我的FM经验：
- 学习曲线比使用硬编码行业标准技术要less得多;
- 由于ODBC和JDBC的连接性，它可以很好地适应行业标准平台。 您的数据未locking在FM中，其他数据格式可以在FM中获得;
- 它适合于前端和后端解决scheme。
- FM可以匹配具有正确数据库devise和部署的企业平台，即面向工作组或部门的解决scheme。 这是工作组所有者的数据，并可用于其他工作组或部门;
- FM非常适合采用原型开发的快速应用程序开发;
- FM还有更多function
我build议你自己尝试一下，我相信你会喜欢FM可以提供的东西！
快乐的计算…
一个小小的研究让我觉得FileMaker确实是Access for Mac，但也许更强大一点。 我和Access一起工作了好几年，从来没有真正喜欢它，并且很高兴远离它（我一直对MSFT杀死FoxPro感到嫉妒，我喜欢它）。
我很难想象它是一个很好的解决scheme，用于全国四个办事处的办公室使用的基于networking的应用程序，以及许多其他人在家里login等。
使用它没有什么意义，当MySQL，SQL Server等可用于数据存储和ASP.NET，PHP，Ruby等编程。
麦克托马斯
虽然与“Access for Mac”的比较是不可避免的，但还是有一些重要的区别。
FileMaker数据库可以共享给不止一个人提供的两件事情之一发生。 一个，你的networking上的一个人打开数据库，并从他们的计算机共享，作为主机。 二，您购买并安装承载数据库的FileMaker服务器。
另外，我的经验是，虽然FileMaker开发者LOVE FM，但他们不得不学习其他技术，因为越来越多的政府机构（我的主要雇主过去10年）正在从FM调入SQL Server，Oracle，并在一定程度上访问和开源。 FileMaker技能在公共领域的需求越来越less，因此获得对这些应用程序的支持变得更加困难，因此更加昂贵。
这就是说，我们有一个FM服务器和FM 5.5客户端运行一个应用程序，在过去的5年稳定。
很多关于FileMaker的评论是非标准的。 但什么是“标准”？ 通过“标准”，许多人意味着数据库支持结构化查询语言（SQL）（ISO标准9075），而FileMaker已经并将继续支持SQL。 每个数据库引擎如何支持SQL是每个数据库专有的。 现在它可能是开源的，比如MySQL，但是SQL是一个支持的标准，而不是它如何完成的底层语言。
当大多数人谈论数据库时，他们只是谈论后端表和模式。 前端用户界面经常是别的。 他们中的大多数现在通过像PHP这样的开放标准将这些结果呈现为html页面。 同样，FileMaker完全支持PHP调用和Apache或IIS（取决于您所在的操作系统平台）。
所以我不同意有人说FileMaker是非标准的。
FileMaker的独特之处在于模式和用户界面之间的紧密集成。 这与苹果在硬件和操作系统之间的紧密集成相似，这有一些好处。 有趣的是，FileMaker是由苹果公司拥有，但我想这是另一个话题。
一般来说，FileMaker的用户界面比大多数开放标准要容易得多，而且大多数人都使用FileMaker的客户端用户界面而不是Web界面。 只有在FileMaker用户界面中支持的许多内容不能在Web浏览器中复制。
通过模式和用户界面的紧密集成，FileMaker确实使应用程序的快速开发变得更加容易。 这使得在大多数情况下开发成本大大降低。
FileMaker的数据库服务可以分布在多达3台机器上，通过Web服务实现原始的负载平衡能力。 尽pipeFileMaker可以轻松支持数百个用户，但如果同时使用数千个用户，则许多只有SQL的数据库（例如Oracle，MS SQL Server，MySQL，Postgres）可以更好地将负载分散到更多的机器上。 基本上，如果您的同时交易量很高，FileMaker不是您的解决scheme。 例如，一个有来自全国各地的许多销售terminal的公司同时打它。
虽然FileMaker支持SQL和PHP，但仅以此方式使用它是浪费在FileMaker用户界面的许可证上花费的资金。 开发Web前端并且仅为后端支付完整的FileMaker许可证费用将不是一个具有成本效益的解决scheme。 因此，FileMaker对PHP和SQL的支持与拥有内部员工解决scheme的公司最好结合在一起，但也希望将其与Web开发团队集成到外部客户中。
最后一点需要注意的是，FileMaker对架构和用户界面的紧密集成使得安全性变得更加容易。 显然，您必须设置组和用户，而且我通常将FileMaker与Active Directory（或Open Directory）集成在一起。 但是，当您使用FileMaker客户端和服务器连接时，打开encryption安全性是服务器上的一个checkbox。 FileMaker处理所有证书并使用AES 256位密码（至less从版本11开始，也许在此之前）。 目前，美国政府认为已经批准了包括第一级绝密通信在内的内容。 在典型的SQL系统中，configuration数据库端的安全性以及用户界面的安全性有很多工作要做，而且比单个checkbox要复杂得多。
FileMaker的目标受众是中小型企业，通常拥有5到200名用户，而且这是一个价格适中的产品，用于为这种规模的企业快速开发数据库。
如果不评论在iPad和iPhone等iOS设备上创build和部署移动解决scheme是多么容易，我不能评论这一评论。 FileMaker Go是一个在这些移动设备上使用的免费应用程序，它们完全支持相同的用户界面和安全性。 事实上，我知道有一家公司使用FileMaker作为Oracle数据库的前端接口，只是为了在iPhone上访问。 未来在移动市场上会有更多的需求，而FileMaker显然是针对移动用户的。
我已经使用FM一年多了。 我正在为中小企业提供使用SQL标准几年的解决scheme。 我喜欢这些SQL的东西，但是就在一年前，我运行了FM Pro 9并试用了它。 令人惊讶的是，我在短时间内得到了所有我想要的东西。 在我作为开发人员的经验中，FM Pro给我留下了深刻的印象。
FM并不是一个行业数据库标准，但它的许多特征可以弥补“标准”的要求。 FM pro具有与MySQL，MS SQL Server和Oracle的实时连接。 对于我来说，如果您可以将数据从FM转移到其他平台，反之亦然，谈标准是没有意义的。
好吧，这个笔记不能说得那么有说服力。 这是很好的尝试自己…特别是现在，FM有它的新版本10.相信我…你会爱上它…
快乐的计算。
有两点似乎主导了这个讨论，需要考虑：
非标准和政府机构在做什么。
让我们考虑一下创build数据库来满足其需求的小企业主或单用户。
现在政府在做什么并不重要，这是你的员工的数据库。 做你想做的事（当然只要是合法的）。
非标准的，往往这是最好的主意，因为你想做的事情适合你。 根据您的喜好命名您的字段和表格，稍后根据您的喜好重新命名。 不要试图用dbf或sql …任何人都记得那些'标准'的文件名bks1999.dbf bks2000.dbf请记住'标准'是存在的，因为别人在你到达之前写了它们，不是因为它们是最好的理念。
是的，有很多“糟糕的”Filemaker解决scheme，但他们正在工作和支持数十万人。 但是，尝试改进这些不好的解决scheme之一，并比较一下改善类似的糟糕的dbf解决scheme的努力。 重命名的字段可以毫不费力地通过相关的Filemaker文件中的数千个脚本和脚本进行过滤。 在dbf解决scheme中，每个实例都必须手动重新input，这可能会变成一场噩梦。
一个真正的testing就是比较Filemaker与SQL等其他应用程序相比如何轻松地工作。 这可能是有趣的。 我从来没有这样做，但我敢打赌，我可以在很短的时间内创build一个工作文件，与这些数据一起工作。
我一直说每个开发者都应该使用和熟悉所有的工具。
Filemaker Pro 25年，FoxPro 3年，4D 2年等
只要把我的2分加到已经给出的答案中： 每个人都已经在投票答案中写的是关于Filemaker的 。 该产品足够强大，以保证正面和负面的意见。
我不是一个足够的专业人员来说明你的问题，但是你可能想看一些用FMP编写的大型复杂应用程序。 丛林软件是一个很好的起点。 对于我来说，作为这些应用程序中的一部分用户，FMP的缺点是它们带有一堆文件。 FMP应用程序的运行时不打包成捆，所以它可能看起来有点复杂，与一个大的应用程序。 我们很久以前做了一些testing，因为FMP有一个缓慢的声誉。 当时（12年前）FMP需要对数据库进行索引，或者它很慢，但一旦被索引，它就像我们testing的其他东西一样快。 对于半专业人士来说，这是一个很大的好处，那就是做基本的东西非常简单，最后是工具。 我在Access方面的经验非常消极，所以我不会和FMP进行比较。
最后，如果软件做到了你想要的，并且稳定地购买它，那么它并不会真正地掌握它的内容。 如果不这样做。 数据进出FMP非常容易，因此数据库格式的专有性并不真正进入。
