潜在客户要求我查看一些属于联系人管理/调度程序类别的应用程序的促销传单.两者都使用Filemaker作为后端.看起来这两个应用程序作为Web应用程序出售.无论如何,我在大约十年内没有听说过Filemaker,所以看到它在同一个座位上弹出两次是令人惊讶的.我认为它最初是作为Mac平台数据库系统.
我更偏爱SQL Server,MY SQL等,但在对Filemaker做出任何评论之前,我想知道一些系统的优缺点.它必须不仅仅是Access for Mac,但我从来没有遇到它作为客户端/服务器或Web应用程序领域的玩家.
非常感谢Mike Thomas
调用Filemaker Pro,Mac的Access就像是说,Mac OS X是适用于Mac的Windows.它们都属于同一类软件,它们是集成的编程环境.就像你有MySQL,PHP,HTML和你的编辑器放在一个GUI中.比较两者,他们都有利弊.以下是根据我的经验使用Filemaker Pro与PHP/MySQL/HTML的优缺点.
优点:
易于上手
易于在本地部署,打开共享并从另一个客户端连接
跨平台(Mac OS X,Windows,iOS)
有许多插件可用于扩展功能
包括启动解决方案
任何有权限的人都可以编辑该程序
在大多数情况下,拖放编程
在事实之后更改字段/数据库/脚本名称是免费的
有一些整洁的内置技巧,如内置图形,选项卡控件,Web查看器
内置支持导入导出excel,cvs,制表格式
缺点:
不灵活:它做得很好,但如果你在大多数情况下需要更多的运气
与免费替代方案相比价格昂贵:本地用户每年花费约100美元,每位开发人员150美元,如果您将其用作需要专门托管的网站,往往会花费更多.此外,该软件的服务器部分每年约为300-800美元
扩展功能所需的插件也很昂贵
几乎只有拖放编程,您只能使用预定义的脚本步骤,通过制作图表来建立关系
源控制是个问题
缺乏可扩展性
无法从解决方案中复制和粘贴/导入或导出某些项目
需要鼠标才能访问功能
布局设计相当静态且过时(使用Filemaker 12及更高版本进行改进)
总的来说,我会说,如果你专门为网络或大型组织开发Filemaker Pro可能不是最合适的.很多人在同一个解决方案上开发很困难.另一方面,对于需要可定制的内部数据库的小型组织来说,这可能是一个很大的好处.如果您愿意处理它的缺陷,您可以使用它快速构建相当复杂的应用程序.
优点:
它很便宜
缺点:
它很便宜(制作)
它是非标准的(很容易找到MySQL/Oracle/MSSQL/Access专家,但没有人知道Filemaker)
使用subpar和/或非标准技术只会产生技术债务.我从来没有找到一个真正享受(或想要)使用这个利基产品的可敬的开发者.
在我看来,这个产品的存在是因为它是Access for Macs,它获得了足够多的用户群和现有的应用程序,足以让每个升级的人购买它以保持业务.市场上有许多产品仍然存在,因为它的用户被锁定,而不是因为它是一个不错的选择.
我承认对这个主题有偏见 - 我和其中一个较大的FileMaker开发商店合作,并写了关于这个主题的奇怪的书.我们实际上聘请了许多喜欢使用FMP的可敬的开发人员.我会尽量保持简短.:-)
FileMaker Pro是一款快速的应用开发工具.它主要是客户端 - 服务器,但它具有一些非常受欢迎的Web发布功能,适用于许多应用程序.它不是基于SQL的,但具有ODBC和JDBC接口,以及XML/HTTP接口.
就锁定而言,FileMaker公司的销售额稳步增长,新用户的增长非常显着,他们对平台的坚固性和易用性感兴趣.
我认为Matt Haughton坚持认为 - 对于正确的应用,FMP只是最好的选择.也就是说,您的客户正在查看使用FMP Pro编写的应用程序,您需要根据自己的优点评估这些应用程序.它们可能是FMP开发的良好实例,或者它们可能不是.
要了解有关FMP适合该任务的更多信息,我们需要了解有关建议的应用程序和用户群的更多信息.这些确实是网络应用程序,还是客户端服务器？有多少用户会使用它？他们是在一个或两个网站上工作,还是在互联网上传播？
如果有更多的兴趣,很高兴进一步阐述.
FileMaker旨在与其他数据库和客户端应用程序进行非常简单的集成.如果您正在构建复杂的分布式系统,请查看其他地方.
由于外部SQL数据源(ESS)功能集的设计目标,FileMaker 不适合用作另一个数据源的前端,并且它不适合用作FM客户端的任何其他内容的后端由于慢速和错误的ODBC驱动程序.FileMaker架构的本质意味着它无法与复杂的解决方案很好地扩展,无论它与其他系统的集成程度如何.
以下是开发人员对FileMaker与其他后端和ODBC客户端合作时发现的一些限制的观点:
ODBC驱动程序有限,速度慢,并且在客户端泄漏内存.xdbc_listender.exe在服务器端具有类似的内存泄漏问题,并且在使用一定量的RAM时最终会崩溃.我们有一个预定的脚本,每晚重启它.
FileMaker需要先将所有相关数据库加载到内存中,然后才能连接到数据库.如果它是一个复杂的数据库,打开和关闭连接可能会很慢(1-2秒),具体取决于它的结构,如果数据库引用其他FM数据库中的表,则更是如此,因为它们也需要加载.我通过创建在应用程序的生命周期内保持打开的持久连接来解决这个问题.虽然我们尝试最小化开放连接的数量,但我们还没有看到服务器上的性能损失.
ODBC驱动程序以奇怪的方式解释查询.例如,我在76k行上运行查询到UPDATE table_1 SET field_1 = 1并且花了5分钟来执行查询,因为我认为它将一个查询拆分为46k更新查询,每行一个.我知道这是因为我看到它在FM客户端中逐个更新行.所以我根本不相信ODBC驱动程序.
这是3个不同查询的另一个例子,以及他们在两个日期字段上搜索的时间:
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如何从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检索和编辑这些文件变得复杂.将文件存储在网络共享上并写入磁盘上的文件要容易得多.
如果必须将FM用作其他数据库的前端解决方案,请务必仔细阅读FileMaker的外部SQL源简介.
另请参阅其网站上的相应版本FileMaker ODBC指南.
关于这个问题的几点评论
在许可成本方面,FileMaker肯定比某些企业解决方案便宜.然而,真正的成本效益是在开发时间.开发生命周期通常比其他企业平台低几个数量级(无论这些平台的许可成本如何).我指的是开发一些功能的几天而不是几周,或几周而不是几个月.
有一个强烈的论点,FileMaker是Mac的Access.虽然几年前这是一个有效的论点,但近年来FileMaker已经出现了.值得注意的是,FileMaker是跨平台的,并且在Windows和Mac上广泛使用.话虽如此,FileMaker和Access之间仍存在巨大的异同,但事实是它们都与您的情况无关.
虽然FileMaker是非标准的,但它确实支持与MySQL,MS SQL Server和Oracle的实时连接.
此外,有许多FileMaker开发人员没有更多标准平台,但他们肯定是,如果你让我知道你在哪里,我可以让你联系你所在地区的一些开发人员.
我想要做的重点是,在正确的环境中,FileMaker是世界上最好的东西 - 如果你尝试做一些不应该做的事情,你就会陷入困境.但是,它可以支持4个地点的办事处,它可以并且正在完成.
在你去其他平台重写你的系统之前,你应该联系一个FileMaker专家,看看他们对你现在所拥有的内容有什么看法,在这个网站上写下更多的细节,让非专家回答是积极的还是消极的不会帮到你.最后,它必须是成本与收益的商业选择.
不需要再列出"缺点" - 但这里有一个重要的"专业" - Filemaker Go.完成数据库设置后,下载ipad/iphone应用程序(FM12免费)并从移动设备运行.数据库可以本地存储在ipad/iphone上,也可以同步回主机PC.
我确信这种移动解决方案在其他地方是可行的 - 但基本点是入门级用户(我的意思是没有以前的数据库经验)可以在几周内创建一个令人印象深刻的解决方案.
个人经验:在我的办公桌下的PC上运行FM 11的主数据库 - 分散在整个城市的4名研究人员在ipads上收集数据 - 所有这些都同步回我的电脑.以前的解决方案是使用纸张并手动输入数据.
FileMaker是一个有趣的应用程序:)它最初是一个最终用户工具,它仍然是非程序员实际可以使用的极少数数据库应用程序之一.但不知何故,FileMaker开发人员设法使其具有很高的可扩展性.没有其他平台可以从一个有用的工具开始,最终得到一个适用于整个公司的客户端 - 服务器应用程序.在过去,他们曾经有一个启动画面,抓住了这个想法(我只发现了一个不完美的版本):
就像文件柜一样简单,可以变大.
FileMaker的所有优缺点都来自它的起源.作为最终用户工具,它与其他DBMS应用程序非常不同.没有SQL.没有真正的编程:脚本基本上是用变量和一些逻辑以更一般的方式重复用户操作的宏.很多限制; 例如,列表视图不能有侧边栏; 动态值列表始终按字母顺序排序; 打开另存为对话框并回读文件名,您需要一个插件; 等等.对于程序员来说,这可能非常令人沮丧,因为他的大多数假设都是错误的.由非程序员编写的现有应用程序并不完全是清晰度和可靠设计的典范.
但是如果你设法克服障碍,你会发现一个相当不错的RAD用于客户端服务器,单用户,网络和移动应用程序,这些应用程序在WAN上可以使用,具有运行时和信息亭模式等细节.
话虽如此,我不太确定FileMaker中的通用联系人管理和日程安排应用程序.如果这是他们的,那么他们应该被解锁,所以客户可以做出改变; 或者他们必须是为客户做的小众应用程序.
京公网安备 11010802040832号 | 京ICP备19059560号-6 