问题描述
在一个单独的SO问题中，我问如何使用db函数填充Maximo字段：
In a separate SO question, I asked how to populate a Maximo field using a db function:
Stack Overflow社区成员很乐意回答问题并提供了以下建议：
A Stack Overflow community member was kind enough to answer the question and provided this advice:
如果我们假设没有任何现成的方法可以做我想做的事情（），然后为什么从Maximo引用数据库功能是一个坏习惯？
If we assume that there aren't any out-of-the-box methods for doing what I want (Spatial Query), then why would referencing a database function from Maximo be a bad practice?
（请记住，我是IT行业的新手。我将从外行的条款中受益。）
推荐答案
我可能会有点冗长，因此我会为此道歉。似乎我在徘徊，但最后我会尽量将其重新组合。
I can be a little verbose, so I'll apologize up front for that. And it may seem like I'm wandering, but I'll try to bring it back together at the end.
正如我在回答第一个问题时所说的那样， ，从自动化脚本中调用存储过程（或存储函数等）不是一种好的习惯。并不是说，从原则上讲，它不应该永远，但通常来说，应该避免这样做。当对良好实践规则进行例外是解决特定问题的最佳方法时，您的代码应记录您为何选择（或被迫）例外。我支持你对第一个问题的回答，而这没有提及特殊情况。
As I said in my answer to your first question, Take value from FieldA, send to db function, return value to FieldB, calling a stored procedure (or stored function or whatever) from an automation script is not "good" practice. That isn't to say, dogmatically, that it shouldn't ever be done, but to say that, as a rule, it should be avoided. When making an exception to the good practice rule is the best way to solve a particular problem, your code should document why you chose (or were forced) to make an exception. And I stand by that answer to your first question, which made no mention of a special circumstance.
如果没有现成的配置选项可以做您想要的东西，例如Maximo中的分频器，关系或域等，那么您的下一个选项应该是产品内自定义选项（也称为小型'c自定义）（如果存在的话）。对于Maximo，您可以使用Python或JavaScript进行自动化脚本编写或自动脚本编写，并且可以使用JVM /服务器的类路径中的所有（Java）类（可能包括Maximo Spatial的Java类方法）来进行产品内定制选项。使用来自，您甚至可以弄清楚如何通过HTTP或HTTPS调用RESTful API，例如ESRI的ArcGIS公开的RESTful API。
If there are no out-of-the-box configuration options for doing what you want, such as crossovers or relationships or domains or etc in Maximo, then your next option should be in-product customization options (also known as "small 'c' customizations), if they exist. It so happens that in the case of Maximo you have "automation scripting" or "autoscripting" in Python or JavaScript, with all (Java) classes in the JVM's / server's classpath at your disposal (possibly including Maximo Spatial's Java class methods), for an in-product customization option. Using examples from Maximo 76 Scripting Features, you can even figure out how to call RESTful APIs, like those exposed by ESRI's ArcGIS, over HTTP or HTTPS.
如果产品内（小的 c）自定义项不如果无法正常工作（例如导致性能问题），那么自定义产品本身（也就是大的 C自定义）虽然可以接受，但通常不被接受。 （通常可以接受，因为许多公司会接受开发大型 C定制的基本原理，但不被支持，因为供应商会要求您删除定制，并在发现问题并且完全可以想象时重现问题。对于Maximo，通常将编写自己的Java类或存储过程视为大型 C定制。
If in-product (small "c") customizations don't work don't work well enough (such as causing performance problems), then it is generally acceptable, though not supportable, to customize the product itself (aka a big "C" customization). (Generally acceptable, as many companies would accept that rationale for developing a big "C" customization, but not supportable, as the vendor will ask you to remove your Customization and reproduce your problem if a problem is found and if it is at all conceivable that your Customization could be contributing to the problem in any way.) In the case of Maximo, writing your own Java classes or stored procedures are generally considered big "C" customizations.
对于Maximo，您可能可以将其推广到任何COTS产品，从存储过程更新Maximo数据被认为是异常糟糕的做法。这是因为此类更新不受Maximo的业务规则和逻辑的约束，这可能导致数据完整性问题，支持问题等。尤其是，触发器通常会假定Maximo在其文档中明确否认对此顺序的承诺时，已按特定顺序进行数据库更新（例如，在父数据之前插入父数据）。 （如果不再使用，它曾经使用过。）
In the case of Maximo, and you could probably generalize that to any COTS product, updating Maximo data from a stored procedure is considered exceptionally bad practice. This is because such updates are not subjected to Maximo's business rules and logic, which can lead to data integrity problems, support problems, and more. In particular, triggers often assume that Maximo has made database updates in a particular order (parent data being inserted before child data, for example) when its documentation explicitly disclaims commitment to such order. (If it doesn't anymore, it used to.)
请记住所有这些，如果开箱即用，Maximo不提供配置功能来满足您的需求，并且即使您不能使用自动脚本执行所需的操作，即使可以访问所有Maximo和Java库（按优先顺序），也可以使用自动化脚本来调用数据库函数来计算您可以通过Maximo存储的值。实际上，在这种情况下，从脚本中调用函数比设置触发器设置值要好得多，因为假设您通过它的API更新Maximo，例如 mbo.setValue（ attribute ，值），您的脚本仍将保留审核，安全性，验证，数据完整性和其他业务规则的运作。作为奖励，您聘用的任何专业Maximo顾问（如我）都会帮助您进行项目开发，从而减少浪费时间（请参阅：您的钱），以弄清您的工作状况以及为什么这样做不会破坏他们。
All that in mind, if out of the box Maximo doesn't provide a configuration for doing what you need, and if you can't use autoscripting to do what you want, even with access to all of Maximo's and Java's libraries (in that order of preference), then it would be acceptable to use an automation script to call a database function to calculate a value for you to store via Maximo. In fact, in that scenario, calling a function from your script would be far better than having a trigger set the value, because, assuming you update Maximo via it's API, such as mbo.setValue("attribute","value"), your script will still leave the auditing, security, validation, data integrity, and other business rules in operation. As a bonus, any professional Maximo consultants (like me) you bring on to help with projects will waste less time (read: your money) trying to figure out what you are doing and why so they don't break it.
我希望能帮上忙。
这篇关于使用db函数填充Maximo字段：为什么这是一种不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！