database Filemaker 的优缺点是什么？

What Are the Pros and Cons of Filemaker?

提问by

A potential customer has asked me to look at some promotional flyers for a couple of apps which fall into the contact management / scheduler category. Both use Filemaker as their backend. It looks like these two apps are sold as web apps. At any rate I had not heard of Filemaker in about ten years, so it was surprising to see it pop up twice in the same sitting. I think it started out as a Mac platform db system.

一位潜在客户让我查看一些属于联系人管理/调度程序类别的应用程序的促销传单。两者都使用 Filemaker 作为后端。看起来这两个应用程序是作为网络应用程序出售的。无论如何，我已经有大约十年没有听说过 Filemaker，所以看到它在同一个座位上出现两次真是令人惊讶。我认为它最初是作为 Mac 平台的数据库系统。

I am more partial to SQL Server, MY SQL, etc, but before make any comments on Filemaker, I'd like to know some of the pros and cons of the system. It must be more than Access for Mac's, but I have never run across it as a player in the client / server or web app arena.

我更偏向于 SQL Server、MY SQL 等，但在对 Filemaker 发表任何评论之前，我想知道该系统的一些优缺点。它肯定不仅仅是 Mac 的 Access，但我从来没有在客户端/服务器或 Web 应用程序领域作为玩家遇到过它。

Many thanks Mike Thomas

非常感谢迈克·托马斯

回答by David Horne

Calling Filemaker Pro, Access for the Mac is kind of like saying, Mac OS X is Windows for the Mac. They're both in the same category of software, they're integrated programming environments. It's like you have MySQL, PHP, HTML and your editor put together in a GUI. Comparing the two, they both have pros an cons. Here are the pros and cons of using Filemaker Pro vs PHP/MySQL/HTML in my experience.

调用 Filemaker Pro，Mac 的 Access 有点像在说，Mac OS X 是 Mac 的 Windows。它们都属于同一类软件，它们是集成的编程环境。这就像您将 MySQL、PHP、HTML 和编辑器放在一个 GUI 中。两者相比较，各有利弊。根据我的经验，以下是使用 Filemaker Pro 与 PHP/MySQL/HTML 的优缺点。

Pros:

优点：

• Easy to get started
• Easy to deploy locally, turn on sharing and connect from another client
• Cross-platform (Mac OS X, Windows, iOS)
• There are many plugins available to extend functionality
• Includes starter solutions
• Anyone with access can edit the program
• For the most part, drag and drop programming
• Changing field/database/script names after the fact is free
• Has some neat built in tricks like built in graphs, tab controls, web viewers
• Built in support for importing exporting excel, cvs, tab-formatted

• 易于上手
• 易于在本地部署，打开共享并从另一个客户端连接
• 跨平台（Mac OS X、Windows、iOS）
• 有许多插件可用于扩展功能
• 包括入门解决方案
• 任何有访问权限的人都可以编辑程序
• 大多数情况下，拖放编程
• 事后更改字段/数据库/脚本名称是免费的
• 有一些巧妙的内置技巧，如内置图形、选项卡控件、网络查看器
• 内置支持导入导出excel、cvs、tab格式

Cons:

缺点：

• Inflexible: it does what it does well, but if you need more your out of luck for the most part
• Expensive compared to the free alternative: It costs about $100 per year for a local user, $150 per developer, if you are using it as a website you need specialized hosting, which tends to cost more. In addition the server part of the software is about $300-$800 a year
• The plugins required to extend functionality can be expensive as well
• Pretty much only drag and drop programming, you can only use predefined script steps, relationships are made by making a graph
• Source control is problem
• Lack of scalability
• Unable to copy and paste/import or export some items from solutions
• Requires the mouse to access functionality
• Layout design is fairly static and dated (this is improving with the Filemaker 12 and above)

• 不灵活：它可以做它擅长的事情，但如果你需要更多，那么在大多数情况下你会很不走运
• 与免费替代方案相比昂贵：本地用户每年花费约 100 美元，每位开发人员花费 150 美元，如果您将其用作网站，则需要专门的托管，这往往会花费更多。此外，该软件的服务器部分每年约为 300-800 美元
• 扩展功能所需的插件也可能很昂贵
• 几乎只能拖放编程，您只能使用预定义的脚本步骤，通过制作图形来建立关系
• 源头控制有问题
• 缺乏可扩展性
• 无法从解决方案中复制和粘贴/导入或导出某些项目
• 需要鼠标访问功能
• 布局设计相当静态和过时（Filemaker 12 及更高版本正在改进）

In general I would say that if you're developing exclusively for the web or a large organization Filemaker Pro probably isn't the best fit. It's difficult to have multiple people developing on the same solution. On the other hand, for a smaller organization in need of a customizable in-house database it could be a great boon. You can build rather complicated applications very quickly with it if your willing to deal with it's deficiencies.

一般来说，如果您专门为 Web 或大型组织进行开发，那么 Filemaker Pro 可能不是最合适的。让多个人在同一个解决方案上进行开发是很困难的。另一方面，对于需要可定制的内部数据库的小型组织来说，这可能是一个巨大的福音。如果您愿意处理它的缺陷，您可以使用它非常快速地构建相当复杂的应用程序。

回答by TravisO

Pros:

优点：

• It's cheap

• 很便宜

Cons:

缺点：

• It's cheap(ly made)
• It's non-standard (easy to find MySQL/Oracle/MSSQL/Access experts but nobody knows Filemaker)

• 它很便宜（制造）
• 它是非标准的（很容易找到 MySQL/Oracle/MSSQL/Access 专家，但没有人知道 Filemaker）

Using subpar and/or nonstandard technologies only creates technology debt. I've never found a respectable dev that actually enjoyed (or wanted to) using this niche product.

使用劣质和/或非标准技术只会造成技术债务。我从来没有找到一个真正喜欢（或想要）使用这个利基产品的受人尊敬的开发者。

In my opinion this product exists because it is Access for Macs, and it gained enough of a userbase and existing applications that enough people bought each upgrade to keep it in business. There are many products on the market that still exist because it's users are locked in, not because it's a good choice.

在我看来，这个产品之所以存在，是因为它是 Mac 版 Access，它获得了足够多的用户群和现有应用程序，以至于有足够多的人购买了每次升级以维持其业务。市场上有许多产品仍然存在，因为它的用户被锁定了，而不是因为它是一个好的选择。

回答by Steve Lane

I'll admit to bias on this subject -- I work with one of the larger FileMaker development shops out there, and have written the odd book on the subject. We actually employ many respectable developers who love using FMP. I'll try to keep it brief. :-)

我承认在这个主题上有偏见——我在一家较大的 FileMaker 开发商店工作，并写了一本关于这个主题的奇怪的书。我们实际上雇用了许多喜欢使用 FMP 的受人尊敬的开发人员。我会尽量保持简短。:-)

FileMaker Pro is a rapid app development tool. It's primarily client-server, though it has some very respectable web publishing capabilities which work well for many applications. It is not SQL-based, but does have ODBC and JDBC interfaces, as well as an XML/HTTP interface.

FileMaker Pro 是一款快速的应用程序开发工具。它主要是客户端 - 服务器，尽管它具有一些非常受人尊敬的 Web 发布功能，适用于许多应用程序。它不是基于 SQL 的，但确实有 ODBC 和 JDBC 接口，以及一个 XML/HTTP 接口。

As far as lock-in, FileMaker Inc has grown sales steadily, with very significant growth in new users who are attracted to the platform's solidity and ease of use.

就锁定而言，FileMaker Inc 的销售额稳步增长，新用户的增长非常显着，他们被平台的可靠性和易用性所吸引。

I think Matt Haughton nailed it -- for the right applications, FMP is simply the best choice going. That said, your customer is looking at apps written in FMP Pro, and you need to evaluate those apps on their own merit. They may be good instances of FMP development, or they may not.

我认为马特·霍顿 (Matt Haughton) 做到了——对于正确的应用程序，FMP 是最佳选择。也就是说，您的客户正在查看用 FMP Pro 编写的应用程序，您需要根据自己的优点评估这些应用程序。它们可能是 FMP 开发的好例子，也可能不是。

To know more about FMP's fitness for the task, we'd need to hear more about the proposed application and user base. Are these indeed web apps, or client-server? How many users will be using it? Do they work at one or two site, or are they spread across the Internet?

要了解有关 FMP 对任务的适用性的更多信息，我们需要了解更多有关提议的应用程序和用户群的信息。这些确实是网络应用程序还是客户端服务器？有多少用户会使用它？他们是在一两个站点工作，还是分布在 Internet 上？

Happy to elaborate further if there's more interest.

如果有更多兴趣，很高兴进一步阐述。

回答by CrazyTim

FileMaker is designed to integrate very simplywith other databases and client applications. If you are looking at building a complicated distributed system, look elsewhere.

FileMaker 旨在非常简单地与其他数据库和客户端应用程序集成。如果您正在考虑构建复杂的分布式系统，请查看其他地方。

FileMaker is NOTgood to use as a front-end to another datasource due to the design goals of the External SQL Data Sources (ESS) feature set, and it is NOTgood to use as a back-end to anything other that the FM client due to slow and buggy ODBC drivers. The nature of FileMaker's architecture means it doesn't scale very well with complicated solutions regardless of how well it can integrate with other systems.

的FileMaker是不是好的作为前端使用另一个数据源由于外部SQL数据源的设计目标（ESS）功能集，它是不是好，因为后端使用到其他的FM客户端什么由于缓慢且有问题的 ODBC 驱动程序。FileMaker 架构的性质意味着它不能很好地扩展复杂的解决方案，无论它与其他系统的集成程度如何。

Here's a developer's perspectiveon some limitations I've found when teaming FileMaker with other back-ends and ODBC clients:

以下是开发人员对我在将 FileMaker 与其他后端和 ODBC 客户端组合时发现的一些限制的看法：

• The ODBC driveris limited, slow, and leaks memory on the client-side. The xdbc_listender.exe has similar memory leaking issues on the server side and will eventually crash when it uses a certain amount of RAM. We have a scheduled script to restart it each night.
• FileMaker needs to load all related databases into memory before it can connect to a database. If its a complicated database, opening and closing a connection can be quite slow(1-2 seconds) depending on how it is structured, and more so if the database references tables in other FM databases because they need to be loaded as well. I get around this by creating persistent connections that stay open for the lifetime of the application. Although we try to minimize the number of open connections, we have yet to see a performance hit on the server.
• The ODBC driver interprets queries in strange ways. For example I ran a query on 76k rows to UPDATE table_1 SET field_1 = 1 and it took 5 mins to perform the query because I think it split the one query into 46k update queries, one for each row. I know this because I watched it update the rows one-by-one in the FM client. So I don't trust the ODBC driver at all.

• ODBC 驱动程序有限、速度慢，并且会在客户端泄漏内存。xdbc_listender.exe 在服务器端也有类似的内存泄漏问题，当它使用一定数量的 RAM 时最终会崩溃。我们有一个预定的脚本来每晚重新启动它。
• FileMaker 需要将所有相关数据库加载到内存中，然后才能连接到数据库。如果它是一个复杂的数据库，打开和关闭连接可能会很慢（1-2 秒），具体取决于它的结构，如果数据库引用其他 FM 数据库中的表，则更是如此，因为它们也需要加载。我通过创建在应用程序的生命周期内保持打开的持久连接来解决这个问题。尽管我们尝试尽量减少打开连接的数量，但我们还没有看到服务器的性能受到影响。
• ODBC 驱动程序以奇怪的方式解释查询。例如，我在 76k 行上运行了一个查询以 UPDATE table_1 SET field_1 = 1 执行查询需要 5 分钟，因为我认为它将一个查询拆分为 46k 个更新查询，每行一个。我知道这一点是因为我看到它在 FM 客户端中一一更新行。所以我根本不信任 ODBC 驱动程序。

Here's another example of 3 different queries and how long they took searching on two date fields:

这是 3 个不同查询的另一个示例，以及它们在两个日期字段上搜索的时间：

SELECT id FROM table
WHERE datefield1 = {d '2014-03-26'}

.5 seconds

。5秒

SELECT id FROM table
WHERE datefield2 = {d '2014-03-26'} 

.5 seconds

。5秒

SELECT id FROM table
WHERE datefield1 = {d '2014-03-26'} OR datefield2 = {d '2014-03-26'}

1 minute 13 seconds!

1分13秒！

• We had problems with how FileMaker cached datafrom an SQL Express database. We tried to run the command to clear the cache, but it didn't always work (spent a lot of time investigating this).
• FileMaker uses pessimistic lockingof records; before editing (from the client or as part of an odbc transaction) FileMaker attempts to lock the row first.
• The FileMaker Server service "prefers" being stopped using the Admin Console (though the Admin Console may sometimes be unable to stop it either). If the FileMaker Server service stops any other way (including power loss, via the management console, or even a normal system shutdown) then some of your databases may become corrupt. Same if a client crashes during an operation, or if the network connection is lost suddenly. The solution for a power loss is to write a batch scriptto try and automate the shutdown, and then buy a UPS and program it to execute your script before the juice runs out. And hope it works. Otherwise backup hourly using the built-in scheduler. Aside: SQL server doesn't have this problem because it can roll back uncommitted transactions.
• Performing backupswith the built-in scheduler actually suspends operations to the database during backup process. ie, if its a large database, then it might take a minute to backup and users will notice the pause because they wont be able to edit/insert, etc.
• If you're using the FileMaker PHP API, take note that you can't use AND and OR together in the same request.
• Running an intensive query using the ODBC driver might be fast on its own, but run the same query simultaneously(as in a multi-user environment) and it will slow down by about 300% exponentially. You will run into speed issues if you're expecting a large volume of intensive queries to hit the database at the same time.
• We have found that when the FileMaker ODBC driver says it has finished an update/insert operation, it still does not guarantee the transaction is committed; it appears that FileMaker will continue to hold the changes in the server cache until the auto-enter calculated fields are evaluated/indexed and then it saves to disc, meaning there may be more of a delay until the record is actually committed. So really the ODBC write operations are not always immediate writes, but rather eventual writes. This delay will be especially evident in complicated tables with many calculated fields and triggers.
• Calculated fields may slow down execution and readingvia the ODBC driver, depending on what is being evaluated. Try to read stored values whenever possible.
• Using BLOB containers: Not Recommended. Storing documents such as PDFs in a container field will inflate your database file size, take longer to backup and complicate the retrieval and editing of those files via ODBC. It's much easier to store files on a network share and write to the file on disk.

• 我们在 FileMaker 如何缓存SQL Express 数据库中的数据方面遇到了问题。我们尝试运行命令来清除缓存，但它并不总是有效（花了很多时间调查这个）。
• FileMaker 使用悲观锁定记录；在编辑（从客户端或作为 odbc 事务的一部分）之前，FileMaker 会首先尝试锁定该行。
• FileMaker Server 服务“更喜欢”使用管理控制台停止（尽管有时管理控制台也可能无法停止它）。如果 FileMaker Server 服务以任何其他方式停止（包括断电、通过管理控制台，甚至是正常的系统关闭），那么您的某些数据库可能会损坏。如果客户端在操作过程中崩溃，或者网络连接突然丢失，则相同。断电的解决方案是编写一个批处理脚本来尝试自动关闭，然后购买 UPS 并对其进行编程以在果汁耗尽之前执行您的脚本。并希望它有效。否则，使用内置调度程序每小时备份一次。旁白：SQL 服务器没有这个问题，因为它可以回滚未提交的事务。
• 使用内置调度程序执行备份实际上会在备份过程中暂停对数据库的操作。即，如果它是一个大型数据库，那么备份可能需要一分钟，用户会注意到暂停，因为他们将无法编辑/插入等。
• 如果您使用FileMaker PHP API，请注意不能在同一请求中同时使用 AND 和 OR。
• 使用 ODBC 驱动程序运行密集查询本身可能很快，但同时运行相同的查询（如在多用户环境中），它会以指数方式减慢约 300%。如果您期望大量密集查询同时访问数据库，您将遇到速度问题。
• 我们发现，当 FileMaker ODBC 驱动程序说它已完成更新/插入操作时，它仍然不能保证事务已提交；FileMaker 似乎将继续保留服务器缓存中的更改，直到自动输入计算字段被评估/索引，然后保存到磁盘，这意味着在实际提交记录之前可能会有更多延迟。所以实际上 ODBC 写入操作并不总是立即写入，而是最终写入。这种延迟在具有许多计算字段和触发器的复杂表中尤为明显。
• 计算字段可能会减慢通过 ODBC 驱动程序执行和读取的速度，具体取决于正在评估的内容。尽可能尝试读取存储的值。
• 使用 BLOB 容器：不推荐。将 PDF 等文档存储在容器字段中会增加数据库文件的大小，需要更长的时间进行备份，并使通过 ODBC 检索和编辑这些文件变得复杂。将文件存储在网络共享上并写入磁盘上的文件要容易得多。

If you must use FM as a front-end solution to another database, make sure to carefully read FileMaker's Introduction to External SQL Sources.

如果您必须使用 FM 作为另一个数据库的前端解决方案，请务必仔细阅读FileMaker 的外部 SQL 源简介。

Also refer to the the appropriate version FileMaker ODBC Guide found on their website.

另请参阅其网站上的相应版本 FileMaker ODBC 指南。

回答by Matt Haughton

Just a few comments on the subject

只是对这个主题的一些评论

FileMaker is certainly cheaper than some enterprise solutions in licensing costs. However, the real cost benefit is in development time. The development life-cycle is typically orders of magnitude lower than other enterprise platforms (whatever the licensing costs of those platforms). By this I mean days instead of weeks, or weeks rather than months to develop some feature.

在许可成本方面，FileMaker 肯定比某些企业解决方案便宜。然而，真正的成本优势在于开发时间。开发生命周期通常比其他企业平台低几个数量级（无论这些平台的许可成本如何）。我的意思是几天而不是几周，或者几周而不是几个月来开发某些功能。

There is a strong argument that FileMaker is Access for the Mac. While this was a valid argument a few years ago, FileMaker has come into its own in recent years. It's worth noting that FileMaker is cross platform and used extensively on Windows as well as Mac. That being said there are still huge similarities and differences between FileMaker and Access, the truth is none of them have any bearing on your situation.

有一个强有力的论据认为 FileMaker 是适用于 Mac 的 Access。虽然这在几年前是一个有效的论点，但 FileMaker 在最近几年已经站稳脚跟。值得注意的是，FileMaker 是跨平台的，并且广泛用于 Windows 和 Mac。话虽如此，FileMaker 和 Access 之间仍然存在巨大的异同，但事实上它们都与您的情况没有任何关系。

While FileMaker is non-standard it does support live connection to MySQL, MS SQL Server and Oracle.

虽然 FileMaker 是非标准的，但它确实支持与 MySQL、MS SQL Server 和 Oracle 的实时连接。

Also, there are numerous FileMaker developers not as much as more standard platforms, but they are definitely about, if you let me know where you are I can put you in touch with a selection of developers in your area.

此外，有许多 FileMaker 开发人员并不像更标准的平台那么多，但它们绝对是关于，如果您让我知道您在哪里，我可以让您与您所在地区的一些开发人员取得联系。

The important point I want to make is that in the correct context FileMaker is the best thing in the world at what it does - if you try to do something that it's not meant to do, you'll get stuck. However, it could support offices in 4 locations, it can and is being done.

我想说明的重要一点是，在正确的上下文中，FileMaker 是世界上最好的东西——如果你试图做一些它不打算做的事情，你会被卡住。但是，它可以支持 4 个地点的办公室，它可以并且正在完成。

Before you go and rewrite your system in some other platform you should get in touch with a FileMaker expert and see what they have to say about what you've currently got, writing more details on this site and having non-experts answer positively or negatively won't help you. In the end it has to be a business choice of costs vs. benefits.

在您开始在其他平台上重写您的系统之前，您应该联系 FileMaker 专家，看看他们对您目前所拥有的东西有什么看法，在此站点上写下更多详细信息，并让非专家做出肯定或否定的回答不会帮你。最后，它必须是成本与收益的商业选择。

回答by Steve Trawley

No need to list anymore "Cons" - but here is a significant "Pro" - Filemaker Go. Once you have your database setup, download a ipad/iphone app (free for FM12) and run it from a mobile device. The database can be stored locally on the ipad/iphone or synced back to a host PC.

无需再列出“缺点”——但这里有一个重要的“优点”——Filemaker Go。完成数据库设置后，下载 ipad/iphone 应用程序（FM12 免费）并从移动设备运行它。数据库可以本地存储在 ipad/iphone 上或同步回主机 PC。

I'm sure this mobile solution is possible elsewhere - but the fundamental point is that an entry-level user (and I mean NO previous database experience) can create an impressive solution within a few weeks.

我确信这个移动解决方案在其他地方是可能的 - 但基本点是入门级用户（我的意思是没有以前的数据库经验）可以在几周内创建一个令人印象深刻的解决方案。

Personal experience: main database running FM 11 hosted on PC under my desk - 4 researchers scattered across the city collecting data on ipads - all syncing back to my PC. Previous solution was using paper and entering in data by hand.

个人经验：运行 FM 11 的主数据库托管在我办公桌下的 PC 上 - 分散在城市各处的 4 名研究人员在 ipad 上收集数据 - 全部同步回我的 PC。以前的解决方案是使用纸张并手动输入数据。

回答by Mikhail Edoshin

FileMaker is an interesting app :) It started as an end-user tool and it still is one of very few database apps that a non-programmer can actually use. But somehow FileMaker developers managed to make it very scalable. There's no other platform where one can start with a useful tool and end up with a client-server app that for the whole company. In old days they used to have a splash screen that captured this very idea (I only found an imperfect version):

FileMaker 是一个有趣的应用程序 :) 它最初是作为最终用户工具使用的，它仍然是非程序员可以实际使用的极少数数据库应用程序之一。但不知何故，FileMaker 开发人员设法使其具有很强的可扩展性。没有其他平台可以从一个有用的工具开始，最终得到一个适用于整个公司的客户端 - 服务器应用程序。在过去，他们曾经有一个启动画面来捕捉这个想法（我只找到了一个不完美的版本）：

I.e. something as simple as a file cabinet that can grow quite big.

即像文件柜一样简单的东西，它可以变得很大。

All FileMaker pros and cons come from its origin. As an end-user tool it's very much unlike other DBMS apps. No SQL. No real programming: scripts are basically macros that repeat user actions in a slightly more general way with variables and some logic. Lots of limitations; e.g. a list view cannot have a sidebar; a dynamic value list is always sorted alphabetically; to open a Save As dialog and read back the file name you'll need a plug-in; and so on. For a programmer this can be very frustrating, because most his assumptions will be wrong. And existing apps written by non-programmers are not exactly paragons of clarity and solid design.

FileMaker 的所有优点和缺点都来自它的起源。作为最终用户工具，它与其他 DBMS 应用程序非常不同。没有 SQL。没有真正的编程：脚本基本上是宏，它们以稍微更一般的方式重复用户操作，并带有变量和一些逻辑。很多限制；例如，列表视图不能有侧边栏；动态值列表总是按字母顺序排序；要打开“另存为”对话框并读回文件名，您将需要一个插件；等等。对于程序员来说，这可能非常令人沮丧，因为他的大多数假设都是错误的。由非程序员编写的现有应用程序并不完全是清晰和可靠设计的典范。

But if you manage to overcome the obstacles you'll find a rather good RAD for client-server, single-user, web, and mobile apps, that stays rather usable over WAN, with such niceties as runtime and kiosk mode.

但是，如果您设法克服这些障碍，您会发现一个相当不错的 RAD 用于客户端-服务器、单用户、Web 和移动应用程序，它在 WAN 上仍然相当可用，具有运行时和信息亭模式等优点。

Having said that, I'm not quite sure about generic contact management and scheduling apps in FileMaker. If this is what they are, then they should be unlocked, so the customer can make changes; or they have to be niche apps that do for the customer what nothing else does.

话虽如此，我不太确定 FileMaker 中的通用联系人管理和日程安排应用程序。如果它们是这样，那么它们应该被解锁，以便客户可以进行更改；或者它们必须是小众的应用程序，可以为客户做其他什么都做不到的事情。

回答by teody

It has been more than a year now since I run through FM and use it in developing solutions for various clients. The following are my FM experience:

自从我使用 FM 并使用它为各种客户开发解决方案以来，已经一年多了。以下是我的FM体验：

1. learning curve is much less than using the hard coded industry standard technology;
2. it can fit well as to industry standards platforms because of it's ODBC and JDBC connectivity. Your data is not locked in FM and other data format can get in FM;
3. it fits well as front end and back end solutions.
4. FM can match enterprise platform having a right database design and deployment i.e. workgroup or department oriented solutions. This is data to it's workgroup owner and make it available for other workgroups or departments;
5. FM is fits well for rapid application development that employs prototyping;
6. FM has many more capabilities you therein...

1. 学习曲线远小于使用硬编码的行业标准技术；
2. 由于它的 ODBC 和 JDBC 连接性，它可以很好地适应行业标准平台。您的数据未锁定在FM中，其他数据格式可以在FM中获取；
3. 它非常适合前端和后端解决方案。
4. FM 可以匹配具有正确数据库设计和部署的企业平台，即面向工作组或部门的解决方案。这是工作组所有者的数据，可用于其他工作组或部门；
5. FM 非常适合采用原型的快速应用程序开发；
6. FM 具有更多功能，您可以在其中...

I suggest you try it yourself and I'm sure you'll love the stuff FM can offer!

我建议您自己尝试一下，我相信您会喜欢 FM 提供的东西！

Happy computing...

快乐计算...

回答by Bruce Robertson

Filemaker is enormously powerful and versatile. Excellent multi-user support. You can create wonderful solutions in Filemaker with document management, web interface, iphone interface, automated publishing support, scheduled scripts, PDF/Excel/HTML reports, XML support, caller ID record lookup, integration of web data (UPS & Fedex linked to order record for example). Extensible with plugins. It's like being in the Home Depot of data. Don't try to build Amazon; other than that what can't you build with it, and faster app dev than most anywhere else?

Filemaker 非常强大且用途广泛。出色的多用户支持。您可以在 Filemaker 中创建出色的解决方案，包括文档管理、Web 界面、iPhone 界面、自动发布支持、预定脚本、PDF/Excel/HTML 报告、XML 支持、来电显示记录查找、Web 数据集成（UPS 和 Fedex 链接到订单）例如记录）。可通过插件扩展。这就像在数据的家得宝。不要试图建立亚马逊；除此之外，你不能用它构建什么，以及比其他任何地方都更快的应用程序开发？

回答by Bruce Robertson

A little research has made me think that FileMaker is indeed Access for Mac, but perhaps a little more robust. I worked with Access for years, never really liked it, and am glad to be away from it (I always held a grudge for MSFT killing FoxPro, which I did like).

一些研究让我认为 FileMaker 确实是 Mac 版的 Access，但可能更强大一些。我与 Access 一起工作了多年，从来没有真正喜欢过它，并且很高兴远离它（我一直对 MSFT 杀死 FoxPro 怀恨在心，我确实喜欢它）。

It is hard for me to imagine it as a good solution for a web based app used by offices in four locations around the country, plus many others logging on from home, etc.

我很难想象它是一个很好的解决方案，适用于全国四个地方的办公室使用的基于 Web 的应用程序，还有许多其他人在家登录等。

Using it does not make much sense when MySQL, SQL Server, etc are available for the data storage and ASP.NET, PHP, Ruby etc are there for the programming.

当 MySQL、SQL Server 等可用于数据存储而 ASP.NET、PHP、Ruby 等可用于编程时，使用它没有多大意义。

Mike Thomas

迈克·托马斯