But it is important to stay clean at this front. User-based models, or working with Client Access Licenses (CAL) also has its pitfalls. Especially CPU based licensing in combination with current virtual environments can be challenging. They vary widely, depending on the vendor, product, edition, and, the worst part, your internal infrastructure. Using world-class features and having to pay for them is ok, but the issue is the terms of licensing. Going for one of the big vendor databases has a downside: It introduces you to the big and ugly world of licensing.
MS SQL makes your initial life easier, but in the long term, it allows you to make many mistakes and not recognizing them until it is too late. But it may be a bit harder to get it to work, but as soon as it works, it's rock solid. For larger environments, with concurrency, Oracle for sure is the best possible solution. A quick read showed me that even FileMaker themselves suggest storing container data outside the embedded system, due to the risk of data loss. With a small vendor's specific database, this may be harder, if not impossible. Knowledge is coming from a huge hit list on the internet and from people like me and my colleagues all over the world. This comes from rock-solid backup and recovery strategies, scalability, advanced-cache recovery strategies, and, not at least, widely available knowledge. If you are asking for long term solutions and looking at the technology side, one of the big vendor databases (Oracle, Microsoft, IBM.) will be way better. But I am into the database business for a long time, so maybe I can help out at this point. I have no experience with FileMaker, so I can't answer any FileMaker specific questions.
0 kommentar(er)
