IDS 对于单用户应用程序来说是一种过度杀戮吗？
我有以下困境：我的客户（妈妈当铺）一直在使用我的管理。该系统使用 ISQL 开发，已有 20 多年的历史。在这二十年中，我根据每个客户的需求或法律/法规的变化需要定制了该应用程序。大多数客户端都是单用户站点。有些人拥有多个商店，但从未想要分布式数据库，不信任互联网或任何其他类型网络的可靠性或安全性。所以，他们都使用标准引擎。我已经能够解决一些 SE 限制，并使用 ISQL 和 SE 完成了一些巧妙的技巧，但迟早，新法律可能会要求当铺客户、商品、电子传输等的图像，然后就到了升级的时候了对于 IDS，请用 4GL 重新编写应用程序或更改为另一个 RDBMS。合乎逻辑且最简单的路线是 IDS/4GL，但是，当我向客户提到 Linux 或类 Unix 平台时，他们反应消极并要求 Windows 平台，因此最简单的解决方案可能是 4Js、Querix 等？...或 Access、Visual FoxPro 或 ???.. 有人有建议吗？
I have the following dilema: My clients (mom-n-pop pawnshops) have been using my mgmt. system, developed with ISQL, for over 20 years. Throughout these two decades, I have customized the app to each clients desire, or when changes in Laws/Regulations have required it. Most clients are single-user sites. Some have multiple stores, but have never wanted a distributed db, don't trust the reliability or security of the internet or any other type of networking. So, they all use Standard Engines. I've been able to work around some SE limitations and done some clever tricks with ISQL and SE, but sooner or later, new laws may require images of pawnshop customers, merchandise, electronic transmision, etc. and then it will be time to upgrade to IDS, re-write the app in 4GL or change to another RDBMS. The logical and easiest route would be IDS/4GL, however, when I mentioned Linux or Unix-like platforms to my clients, they reacted negatively and demanded a Windows platform, so the easiest solution could be 4Js, Querix, etc.?.. or Access, Visual FoxPro or ???.. anyone have suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
整个问题可能归结为您必须处理的几个问题。
首先是您愿意学习和使用什么应用程序编程和开发语言？
另外一个就是你想要什么样的互联网能力？
例如，在查看报告时，您是否希望能够单击按钮并将报告转换为 PDF 文档，然后启动附有该 PDF 的电子邮件客户端？
那么，在他们将所有信息数据输入系统后，也许每个商店都想要自己的微型网站，城里的人们可以去那里检查他们有什么，需要打电话给商店询问是否有有一个 3 美元的二手打火机（打电话和检查这些便宜物品的劳动量比销售该物品的成本还要多——所以网络对于这种情况来说真的很棒）。
另一个问题是你想要什么样的界面？我假设您目前有某种类型的绿屏或基于文本的界面？或者也许多年来您确实转换为 GUI（图形用户界面）。
如果仍然是绿屏（基于文本），您现在必须坐下来，投入大量的精力和时间来进行布局以及屏幕如何与基于图形的系统一起工作。我记得当从绿屏转向彩色时，突然之间，必须为该屏幕选择正确的颜色和布局的选择和努力实际上增加了相当多的工作量。然后我从颜色测试屏幕转到图形界面，然后突然之间我们又看到了大量新的控件、颜色，除此之外我们在不同的字体方面有很大的选择和尺寸。
现在有了网络，你不仅要处理不同类型的按钮样式（圆形、椭圆形、阴影、阴影、发光效果），而且除了所有这些悬停效果和阴影效果等之外，你现在还必须停下来一些非常严重的问题，例如您的软件将为整个网站采用哪种颜色（主题）。
这实际上取决于您愿意在新工具上投入多少学习和时间，以及在给定的时间和精力下您可以并且将会生产多少软件。
当你进入小型企业市场时，我非常偏爱 RAD 工具。大多数小型企业无法承担 .net 开发人员的费用（与其说是费用，不如说是构建应用程序的时间）。因此，在小型企业市场中使用 ms-access 是一个不错的选择。 Access 仍然是市场上其他工具的 3 到 5 倍。因此，.net 开发人员开发某些东西的报价可能是 12,000 美元，而在 Access 中开发同样的东西可能是 3000 美元。我的意思是，小企业无力支付你编写单元测试代码的费用。这种类型的额外成本在较小规模的项目中不会发生。
您必须处理的另一个大问题是您要在系统中构建什么样的报告编写系统？这是我喜欢较小的业务应用程序的另一个原因是访问是因为报告编写器真的很棒。 Access 报告具有一系列功能，可以从表单和查询中烘焙连接，并将过滤器和参数传递到这些报告中。而且，通常您花时间构建的表单和查询已经可以与带有参数的报表进行交互并以再次真正减少工作量（开发成本）的方式传递值。
我认为您在这里必须解决的第一个问题是您要为基于网络的策略做什么？你绝对必须拥有一个。即使您在 Access 中构建前端部分，您可能仍然希望使用 SQL Server 的免费版本作为后端部分。造成这种情况的原因有很多，但其中一个原因是它可以轻松地通过互联网连接多个商店。
将数据放入某种类型的基于服务器的系统中的另一个优点是，现在您可以设置某种类型的网络服务器供所有商店使用，并构建一个小型定制系统，允许每个商店在线提供其产品和列表（但是，他们使用您的网络服务器，或者您每月支付 15 美元的网络服务器来托管所有这些客户）。此 Web 部件可能是一个可选组件，也许并非所有客户都需要。无论如何，它将利用他们必须输入系统的数据。
采用这些基于网络的系统的一大优势是，它不仅可以让这些商店更好地为客户服务，而且还为您打开了大门，将您的软件转换为按月付费的系统，或者至少是按月付费的系统的一部分。它例如您提供的可选网络托管部分。
当我将使用时间较长的应用程序从绿屏大型机类型软件转换为基于 Windows 桌面的应用程序时，它为我打开了巨大的市场。通过远程桌面、下载软件、从网站发布更新，这些新的软件系统使交付软件的所有这些细节变得非常容易，尤其是在为您从未见过面的不同城市的客户提供支持时脸。
因此，如果您仍然主要谈论单个用户和一个位置，Access 将大大降低您的开发成本。这实际上取决于您所讨论的应用程序的复杂程度和丰富程度。如果项目的规模和范围超出了一名开发人员的范围，那么您将更多地谈论开发人员扩展（源代码控制、对象开发方法、单元测试、设置基于服务器的数据库系统（如 SQL Server 等）的成本和时间）。因此，当您超出复杂城市中成本时间的临界点时，它们肯定是临界点，那么我实际上不建议访问。因此，这一切都取决于选对马、走对路。
也许归根结底，这真的取决于您愿意投入时间学习哪种应用程序开发系统？
This whole issue probably comes down to a couple of issues that you'll have to deal with.
The first thing is what application programming and development language Are you willing to learn and work with?
The other thing is what kind of Internet capabilities to you want?
So for example while looking at a report do you want to be able to click on a button and have the report converted to a PDF document, and then launch the e-mail client with that PDF attached?
What about after they enter all the information data into the system, perhaps each store would like their own miniature web site in which people in town could go there to check what they've have place of having to phone up the store and ask if they have a $3 used lighter (the labor of phone and checking for these cheap items is MORE than the cost of selling the item – so web really great for this type of scenario).
The other issue is what kind of interface do you want? I assume you currently have some type of green screen or text based interface? Or perhaps over the years you did convert over to a GUI (graphical user interface).
If still green screen (text based) you now you have to sit down and give a considerable amount of effort and time into the layout and how you of screens will work with a graphical based system. I can remember when going from green screens to color, all of a sudden now the choices and effort of having to choose correct colors and layouts for that screen actually increased the workload by quite a bit. And then I went from color test screens to that of a graphical interface, then again all of a sudden now we're presented with a large number of new controls, colors, and in addition to that we have large choices in terms of different fonts and sizes.
And then now with the web, not only do you deal at different kinds a button styles (round, oval, shading, shadows, glow effects), but in addition to all those hover effects and shading effects etc, you now have to get down to some pretty serious issues in terms of what kind of colors (theme) your software will adopt for the whole web site.
This really comes down to how much learning and time you are willing to invest into new tools and how much software you can and will produce for given amount of time and effort.
I quite partial to RAD tools when you get down into the smaller business marketplace. Most of the smaller businesses can not afford rates for a .net developer (it not so much the rate, as the time to build an application). So, using ms-access is a good choice in the smaller business market place. Access is still a good 3 to 5 times many of the other tools in the marketplace. So quote by .net developer to develop something might be 12,000 bucks, and the same thing in Access might be $3000. I mean that small business can not afford to pay you to write unit testing code. This type of extra cost is just not going to happen on the smaller scale projects.
The other big issue you have to deal is what kind of report writing system are you going to build into the system? This is another reason why I like for the smaller business applications is access is because the report writer is really fantastic. Access reports have a whole bunch of abilities to bake connections in from forms and queries and pass filters and parameters into those reports. And, often the forms and queries that you spend time building already can talk to reports with parameters and pass values in a way that again really reduces the workload (development costs).
I think the number one issue that you'll have to address here however is what you're going to do for your web based strategy? You absolutely have to have one. Even if you build the front end part in access, you might still want to use a free edition of SQL server for the back end part. There are several reasons for this, but one reason is then it makes it easy to connect multiple stores up over the Internet.
Another advantage of putting your data in some type of server based system, is now you can set up some type of web server for all the stores to use, and build a tiny little customize system that allows each store to have their products and listings online (but, they use YOUR web server, or one that you paying $15 per month to host all of those customers). This web part could be an optional component that maybe perhaps all customers don't necessarily want. It would work off of the data they have to enter into the system anyway.
One great advantage of adopting these web based systems is not only does it allow these stores to serve their customers far better, but it also opens up the doors for you to convert your software into a monthly fee based system, or at least some part of it such as the optional web hosting part you offer.
When I converted so my longer time applications from green screen mainframe type software into windows desktop based applications it opened up large markets for me. With remote desktop, downloading software, issuing updates from a web site, then these new software systems make all of these nuts and bolts part of delivering software very easy now and especially so for supporting customers in different cities that you've never met face to face.
So, if you talking still primarily single user and one location, Access will reduce your development costs by a lot. It really depends on how complex and rich of an application you are talking about. If the size and scope of the project is beyond one developer, then you talking more about developer scaling (source code control, object development methodology, unit testing, cost and time of setting up a server based database system like SQL server etc). So they're certainly tipping point here when you go beyond that tipping point of cost time in complex city, then I actually don't recommend access. So this all comes down to the right horse for the right course.
Perhaps that the end of the day, it really comes down to what application development system are you willing to invest the time to learn?
看看 Aubit4GL - 也就是说，我相信，可用（或可以编译上）Windows。
是的，对于单用户系统来说，IDS 已经近乎杀伤力了，但如果 SE 不能提供您需要的所有功能，或者预计在不久的将来需要的功能，那么它是一个非常明智的选择。然而，只要稍加注意，就可以将其设置为（基本上）对用户完全不可见。而且对于像这样无压力的应用程序来说，配置并不复杂。作为供应商，您需要对此非常了解。但是，还有静默安装等功能，您可以让自己的安装程序运行 IDS 安装程序，从而将软件轻松安装到客户的计算机上。系统的总大小将会增加 - IDS 在磁盘上比 SE 大得多（但您可以获得更多的功能）。还有一些机制可以删除您可能不会使用的较大代码块。例如，您可能会使用 ON-Tape 进行备份；因此，您在运送给客户的货物中会省略 ON-Bar 和 ISM。
IDS 用于没有用户和管理员使用系统的嵌入式系统。硬件位于橱柜中并通过网络进行通信。
Look at Aubit4GL - that is, I believe, available (or can be compiled on) Windows.
Yes, IDS is verging on overkill for a single-user system, but if SE doesn't provide all the features you need, or anticipate needing in the near future, it is a perfectly sensible choice. However, with a modicum of care, it can be set up to be (essentially) completely invisible to the user. And for a non-stressful application like this, the configuration is not complicated. You, as the supplier, would need to be fairly savvy about it. But there are features like silent install such that you could have your own installer run the IDS installer to get the software onto the customer's machine without extra ado. The total size of the system would go up - IDS is a lot bigger on disk than SE is (but you get a lot more functionality). There are also mechanisms to strip out the bigger chunks of code that you won't be using - in all probability. For example, you'd probably use ON-Tape for the backups; you would therefore omit ON-Bar and ISM from what you ship to customers.
IDS is used in embedded systems where there are no users and no managers working with the system. The hardware sits in the cupboard (closet) and works, communicating over the network.
很高兴看到人们仍然从“老式”Informix 工具中获得价值。我从来不擅长 Perform，但 ACE 报告编写器总是适合我。我们跳过了 Perform，直接选择了 FourGen，我遗憾的是我从来没有像使用 FourGen 那样高效。它有自己的优雅，从代码生成器到时髦，但实际上放弃了强大的独立菜单系统。
我很欣赏现代的 UI 动态，但是，该死的，现在编写应用程序很难吗？不仅仅是工具，还有行业需求等（例如您可能在您的领域中遇到的情况）。而网络就是彻头彻尾的谋杀。
我想部分原因是因为大多数“绿屏”应用程序看起来都一样，所以很难制作一个看起来很糟糕的应用程序！借助 GUI 和 Web 等，您无法简单地获得良好的字段顺序和排列好的标签。
但是，唉，事实就是如此，这就是我们所拥有的。
我已经有 15 年没有使用过它了，但您可能还想看看 Alpha 5。它是一个非常强大但不太复杂的数据库开发包，并且（显然）仍然很强大。
我不会太害怕IDS。它运行起来非常简单。开箱即用，只需进行零或很少的调整，数据库就可以工作并且高效，并且安装起来非常简单。它不是 SE，因为 SE 的访问与应用程序（使用库）相关联，而不是独立服务器（即 IDS）。但是，从操作上来说，它非常简单——尤其是对于像您所说的这样的应用程序。我知道这可能有些过分，但即使在今天，资源需求也不一定是疯狂的。当然，有很多功能和灵活性您不会使用。但坦率地说，除了“平面文件”DBase 样式数据库之外，几乎所有基于服务器的 SQL 数据库都非常强大且功能强大，但可能很复杂。但他们不必如此。它们仍然可以“简单”且轻松地使用（好吧，除了 Oracle——Oracle 不能“简单”做任何事情）。
至于探索其他解决方案，不要太害怕“OOP”的东西，因为大多数应用程序虽然利用 OOP 库，但它们本身并不是真正的 OOP（它们可以是，但通常不是，它们只是不需要）。许多 OOP 系统的最大问题是它们的结构过于精细。以太低的水平处理事件。虽然许多程序需要访问这种精细的控制级别，但大多数应用程序，尤其是那些与您的应用程序非常相似的应用程序，却不需要。因此，额外的灵活性只会妨碍或产生更多的样板。
也就是说，您不应该因为缺乏专业知识而害怕他们本身。它们可以相当快地被拾取。但我肯定会首先用尽更专业的工具（如 Alpha 5 或 Access 等），看看它们是否不能提供您想要的东西。
It's good to see folks still getting value out of "old school" Informix Tools. I was never adept at Perform, but the ACE report writer always suited me. We skipped Perform and went straight for FourGen, and I lament that I've never been as productive as I was with FourGen. It had it own kind of elegance from its code generators to it funky, but actually quit powerful, stand alone menu system.
I appreciate the modern UI dynamics, but, damn, is it hard to write applications today. Not just tools, but simply industry requirements et al (such as you may be experiencing in your domain). And the Web is just flat out murder.
I guess part of it is that since most "green screen" apps look the same, it's hard to make one that looks bad! With GUIs and the Web etc., you can't simply get away with a good field order and the labels lining up.
But, alas, such as it is, that is what we have.
I have not used it in, what now, 15 years, but you may also want to look at Alpha 5. It was a pretty powerful, but not overly complicated, database development package, and (apparently) still going strong.
I wouldn't be too afraid of IDS. It runs pretty simply. Out of the box with zero or little tweaking, the DB works and is efficient, and it used to be pretty trivial to install. It was no SE, in that SE's access was tied to the application (using a library) vs an independent server that is IDS. But, operationally, it's really straightforward -- especially for an app like what you're talking about. I appreciate that it might be overkill, but even today, the resource requirements won't necessarily be insane. There's a lot of functionality, of course, and flexibility that you won't use. But frankly, beyond "flat file" DBase style databases, pretty much ALL of the server based SQL databases are very powerful and capable and potentially complicated. But they don't have to be. They can still be used "simply" and easily (well, save for Oracle -- Oracle can't do anything "simply").
As far as exploring other solutions, don't be too afraid of the "OOP" stuff, as most applications, while they leverage OOP libraries, aren't really OOP themselves (they can be, they just typically aren't, they simply don't need to be). The biggest issue with many of the OOPs systems, is they're simply to finely structured. Dealing with events at far too low of a level. While many programs need to access to that fine level of control, most applications, particularly the ones much like yours, do not. So, the extra flexibility simply gets in the way or creates more boiler plate.
That said, you shouldn't be frightened away from them per se, citing lacking of expertise. They can be picked up reasonably quickly. But I would certainly exhaust the more specialized tools (like Alpha 5, or Access, etc.) first to see if they don't offer what you want.
就 Visual FoxPro 而言，无论过去还是现在，它都是一个无与伦比的工具（尽管受到对其知之甚少的人的猛烈抨击）。它具有快速、原生的数据库引擎、内置的SQL和强大的报表设计器等。但你也必须考虑到微软将在2014年放弃对它的支持，永远不会有64位版本，等等。而且它使用的文件锁定方法在 Windows IMO 的未来版本中将变得越来越不稳定。
In terms of Visual FoxPro, was and remains a peerless tool (despite flak from people who know little about it). It has a fast, native database engine, built-in SQL and powerful report designer and so on. But you also have to consider that Microsoft support will be dropped for it in 2014, there will never be a 64-bit version, and so on. And the file locking method it uses will be increasingly flaky on future versions of Windows IMO.