I work for a healthcare company with less than 1,000 employees.
I am new to FileMaker Pro but my company uses FileMaker Pro (FM Pro) as the frontend development tool. More and more applications will be built using FM Pro.
In the long run :
1. Is FM Pro Embedded DB or MS SQL Server a better choice in the long run for the backend database?
2. What are the pros and cons of using these two d...
Senior Database Consultant at Performing Databases
May 11, 2020
I have no experience with FileMaker, so I can't answer any FileMaker specific questions. But I am into the database business for a long time, so maybe I can help out at this point.
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. This comes from rock-solid backup and recovery strategies, scalability, advanced-cache recovery strategies, and, not at least, widely available knowledge. Knowledge is coming from a huge hit list on the internet and from people like me and my colleagues all over the world. With a small vendor's specific database, this may be harder, if not impossible. A quick read showed me that even FileMaker themselves suggest storing container data outside the embedded system, due to the risk of data loss. For larger environments, with concurrency, Oracle for sure is the best possible solution. But it may be a bit harder to get it to work, but as soon as it works, it's rock solid. 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.
Going for one of the big vendor databases has a downside: It introduces you to the big and ugly world of licensing. Using world-class features and having to pay for them is ok, but the issue is the terms of licensing. They vary widely, depending on the vendor, product, edition, and, the worst part, your internal infrastructure. Especially CPU based licensing in combination with current virtual environments can be challenging. User-based models, or working with Client Access Licenses (CAL) also has its pitfalls. As I said, it's not nice. But it is important to stay clean at this front. For a tease, as long as you stay small, vendors like Microsoft and Oracle (not sure with IBM) also offer free editions of their products, with limited sizes/resources, but with a large and valuable technology stack.
Going for free technology? I'd always recommend PostgreSQL then. PGSQL is not as scalable as Oracle is, but if you don't need much click-and-play stuff, it gives you most of what MS SQL would also bring. But when reading through FileMaker's web page, I can see you need an "Actual Technologies Adapter", no clue if this has any downsides.
One thing for sure: A database is no playground if you have important data to store. Make yourself familiar with the technology, or ask for educational support early in the process, to avoid long-term mistakes. People like myself are offering all kinds of help, from a free response in mailing lists up to on-site hands-on training.
Does running Oracle 11g and 12c databases under OLTP type workload on SPARC architecture really offer performance benefits compared to a similar specification Intel based server (keeping the Core-count same to remove the licensing from the picture)?
Database Senior Manager at a financial services firm
Oct 30, 2017
In my experience SPARC provides far better performance than x86 based server. Databases are more responsive and way quicker to start. Recently, I had the privilege to run 70(Yes, 70) databases on a single E25k SPARC server with around 256GB RAM. No issues whatsoever. Try running half of that on a x86 based server and it would be a disaster. Having said that, I am sure you must have read that Oracle has stopped further development of SPARC which indirectly means that it will stop SPARC sooner rather than later. Would you still want to use/move to SPARC servers?
I will echo Bobin's observations re: Oracle stopping development. I think the key is to look at the price drops in high-end hardware, and scale out on a 1.5x ratio if migrating from SPARC to x86. Also, look at virtualization low-churn loads, and segment your database stores based on usage analytics and HA services.
Backup and replication options.
At the first based on my experience we need to calculate software or customer requirements and after that choose the best option. Today all databases have the same options with little difference like Data types, HA, Performance, Security, Backup/Recovery, etc.
for example if you want to design a software with just 5 to 20 users, is that reasonable to use Oracle database service ?
however, from a programmer's point of view evaluating Relational Databases are rated by features like Datatypes, Functions, Index types and etc, DBA's (Database Administrators) vision is different. So my list is
- TCO (Total cost of ownership)
- High Availability Solutions.
- Backup / Restore solutions.
- Data Capacity and Security.
- Memory Management.
- Inmemory Database, Tablespace, Table.
- 3rd Party software
1. Backup and recovery
2. Data security
An Oracle logo.
Top in my list
A single reason is not enough, we can rank the following reasons:
- Operational Performance (OLTP, DWH - ETL)
- Relate to hardware such as disk (storage), memory, cpu and how well they can use them
- Data Capacity
- Data Security
- Application Support
- Vendor Support
The most important is "Solid backup and recovery solution." Imho.
Performance, Security, Quiet Easy to Implement the database Solution, Excellent database tools for managing the Database Environment for example Microsoft SQL Server Management Studio.
Performance, Security, Vendor Support and Price
Definitely Performance, Data mining, easy use.
We should evaluate mainly performance of the database as well as pricing of the database.
- If you want to host application which has small amount of data and does not have secure content in it you can go for open source databases.
- vice versa, if your data has secure or critical contents in it then we should consider security features of database as well.
- one more important feature we need to consider now a days is parallel distribution/parallel computing feature e.g. Postgresql / greenplum has this feature.
Modeling features (from physical to business), sql optimization / mdx support, easy of use
mainly the performance. For RDBMS you would not be having any performance issue. But when it comes for data loading, RDBMS would not be a good take. This of an MPP where the data is spread accross segments
Scalability and performance, both in relation to volume of data and concurrent queries.
scalability and platforms DBMS runs on
Ease of use
Examples of complex statements or auto creation of queries
If it covers all of the project needs/specifications.
Vendor support, product track record, scalability, clustering options and security.
First Knowledge of the platform, performance, backup/restore...
Easy integration, fast ,scalability to needs and support for all developer APIs
only one reason as of today, that is transactional atmoicity, don't see any other; you open source them with light versions and see the miracles; graph databases are evolving and once there cn be a better fit not just for social as they are today;
Performance, ease of use, scalability and support for all developer APIs.
There's no "most important" criteria when choosing a tool, and a RDBMS is just a tool. If you're running Twitter, then the key factor is performance. If you're running a small medical clinic software, then you need data integrity above the others.
The most important criteria for our customers at NuoDB is that our distributed SQL database has a flexible deployment model that allows them to run the database on a single server machine, across machines in a data center or public cloud, and even on a global basis (across multiple data centers) without having to architect a new solution for each use case.
Scalability, performance and Business Intelligence capability from ETL to warehousing and analytics. Also how well the database solution can be leveraged in an enterprise development organization. There are many more options these days but not from a mature development to deployment and maintenance standpoint.
Reliability, scalability, security, performance, ease of management.
The RDBMS that are known for its Scalability, Availability and its OLTP performance. However am exploring its Analytical functional capabilities. I have been using Sybase IQ EDW. its serves the purpose now. However moving towards building an Enterprise Data Warehouse –Data Lake, researching about MSSQL DW 2014
performance, scalability & security
Can't answer this blindly. Depends on why I'm researching a relational db technology and what the requirements are.
Ability to retrieve as and when required in any format to give valuable insights to business.
Easy for support and use. Set of high availability features.
operational efficiency and simplicity of use and understanding ( set of features ) has a high value in any case.
performance, security, and it allows OO_RDBMS
Wide adoption, Performance, Scalability, Replication, Failover.
1. Performance 2. Ease of using analytic functions 3. Industry hold
Performance and security
Existing organisational capabilities. e.g; introducing Oracle to a team already skilled in MSSQL would likely be a mistake. Beyond that, I haven't 'researched' RDBMSs for some time. The choice is usually clear for me. MSSQL, MySQL or Postgres.
Scalability and performance.
Do we actually need any of the 'relational' part or can we leverage an object db or something even more lightweight?
Organised, Relationship establishment between objects, Atomic, Security.
Performance, period. Needs to provide a variety of ways to move and process data quickly leveraging disk, processors, RAM, and IO.
Meets Availability requirement, performance and recovery time objective.
Ease of use is also important as well as utilities to load and unload data.
Compatibility. If the database engine doesn't work well with the software you want to use it with, the rest of the features just don't matter. After that, performance and scalability.
Ease of use, scalability, and portability.
Performance and more performance. Go hand in hand with the best technologies Disk.
The data bases footprint in the current market. For example I am reviewing things. MS Access has been a relational database I thought had a footprint and a future. The stuff I read online about the 2013 upgrade and Office 365 have me thinking maybe my ideas need to shift to something else.
Scalability, reliability, performance, ease of management and adherence to standards.
Replication, failover and performance.
Reaction to system failure
The most important criterion is whether the DB comes with a mature BI stack.
The metadata and the less "case when" script.
Concurrency control, analytic functions and indexing options
Ease of use as for uniformed command line and syntax, JOIN performance and features to be able to create sub join / sub view. Community support and widespread use. Availability on documents and technical know - how.