Advantage and disadvantage of Filemaker?

[Anh_Tran]

Dear All,

I am going to convince my client using Filemaker . But I don't know the advantage and disadavantage of Filemaker versus Ms-Access and Oracle. Someone could give me the important key? . Is there a case that you program intelligently different with th books told you?

I am really appreciated.

Thanks

[andygaunt]

Check out the white papers available at www.filemaker.com under their downloads section

here are a couple of the links

http://www.filemaker.com/downloads/pdf/fm_vs_access_overview.pdf

http://www.filemaker.com/downloads/pdf/fm_access_comparison.pdf

[Anh_Tran]

Thanks Andy Gaunt

Anh

[Kurt Knippel]

Something else to think about is also the fact that someone should NOT be considering a choice between Access and Filemaker and Oracle. They are for the most part soooo different that the only commonalities is that they can all be labeled "databases".

The comparison is akin to choosing between a Sedan, a Pickup Truck and a Cargo Container, because that could all be considered "vehicles"

Access alone is NOT a solution, although it can be a bad one. Access was designed as the database back-end to Visual Basic and as a stepping stone to MS SQL Server based application. Access can be powerful, but is very difficult to program and 90% of the time look horrible, its multi-user features are also very poor, unless you connect to a SQL Server and then why use Access when there are lots of better front-end tools available. While I would not recommend Filemaker in every situation, the only situation, where I could recommend the use of Access is as a DB for a single user Visual Basic app.

Oracle is a very powerful database SERVER. It is an engine and storage container, but has no front end. This must be built with something else. Oracle is arguably the most powerful database server available, but I would consider it over-kill in all but big enterprises or high volume solutions. Oracle also require a pretty high priced DBA to operate effeciently.

Filemaker is a mid-range solution, which comrpises both front-end as well as database server functionality and could comfortably be adapted to use in small and medium sized businesses as well as workgroups within larger enterprises. Filemaker is also VERY EASY to use and develop in as well as fairly scalable in its deployment. I consider the upper limit of Filemaker's capabilities to be concurrent 250 users, once this is exceeded, then there are better solutions to develop with. All the other actual limitations of Filemaker are so easy to get around, but the users limit is a tricky one.

[Ugo DI LUCA]

Why is the 250 users a max ?

[Vaughan]

That' the maximum simultaneous connections FM Server will allow.

[Kurt Knippel]

And since only 250 user can connect to a single server, this means that unless you want to install multiple copies of a solution on multiple server, 250 users are the max for any solution.

[davest]

I agree with captkurt's analysis but would advise taking a few further points into consideration.

If you need other systems to read data in a Filemaker database there is a problem.

The XML as offered in FM 6.0 relies on exports and is therefore not dynamic and it also relies on XLS to convert the XML into a form that other products can understand, if they support XLS at all. Provision of dynamic XML is effectively by encapsulated CDML queries requiring FM Unlimited. I have found documentation and support for these areas weak.

The JDBC driver offered won't help much besides only supporting a very rudimentary subset of SQL.

Since Filemaker is not a truly relational database overcoming problems presented by this limitation becomes a constant theme in database development As users demand more of the system the complexity of the workarounds increases.

In conclusion for a simple client-server implementation not requiring connectivity to other products yes FM's RAD is awesome.

Otherwise maybe it would be better and bite-the-bullet and choose another option as described by captkurt.

[Rangoon]

Davist,

RE: Since Filemaker is not a truly relational database.

Rumor has it that FMP 7 will be "truly relational". You talk to the folks at FM and they sound like Government boys doing the ol two step. "They cannot confirm or deny". It's like the Two Eskimos sitting in a kayak were chilly, but when they lit a fire in the craft, it sank, proving once again that you can't have your kayak and heat it,

too.

hj

[jasonwood]

Just curious... what is it about FileMaker that makes it fail to be "Truly Relational"?

[Rangoon]

This explanation is quite technical for most but here it is.

The wagsapner fluxurometer that runs paralel to the hindgopner is inexplicably circuited to the masterquipster. Simply stated FMP is not

[Kurt Knippel]

When people say "truely relational" they generally mean multiple tables in one file.

While this is something that we'll likely see, this does NOT make a DBMS truly relational. In fact most RDBMS are not even truely relational, but they implement enough relational database theory to work well, without too much complexity.

[kennedy]

"No commercial relational database product is fully compliant with the relational model. FileMaker is not alone in that it does not fully comply with the model." -- Moyer and Bowers

So, the question then is: Specifically, what relational model can you not implement or what relational operator can you not perform with FileMaker that you can with Oracle or DB2? (The assumption being that Oracle and DB2 would be the RDBMS's with the most relational functionality.)

This is not a rhetorical question... I actually need to know. All input appreciated.

[BobWeaver]

I think the answer is also in Moyer and Bowers in the summary at the end of chapter 2. You can accomplish pretty much any operation in FileMaker that the relational model specifies, but in several cases the method is somewhat indirect or a bit messy.

[kennedy]

That's not really an answer... "accomplish pretty much any" doesn't answer the question... that just admits there are a few unnamed things that cannot be accomplished... the question is, "of the stuff that cannot be accomplished due to it not being fully compliant, what can be accomplished in Oracle or DB2?"

Or the even more challenging question, "What is far easier in Oracle or DB2 than FMP, relationally speaking?" (not asking for answers like "serving a DB to 5000 users" or "providing a full JDBC interface")

[davest]

I am no academic, I just work with Filemaker (and a RDBMS) here are my thoughts. (Also I really don't want to teach anyone's Grandmother to suck eggs!)

Up in an ivory tower is relational database theory.

In the real world there are Oracle, DB2, SQL Server etc.

These databases have the Structured Query Language (SQL) as their primary method of access and manipulation. SQL from each of these fiercely competitive products amazingly adheres fairly closely to an international standard.

Traditionally data analysis involves at some stage a process of normalisation resulting in a series of tables forming the basis of a database implementation.

SQL will join data from two or more tables which have relationships to each other.

Filemaker does not follow the SQL standard.

Consider a Project management company that invoices a customer for items and services provided by various suppliers.

There is an invoice with many supplier lines and the customers details

The supplier lines have many invoice lines as well as the supplier details.

The invoice lines in turn get their description and up-to-date prices from separate tables.

SQL based implementation and retrieval is relatively straightforward.

Filemaker is not straightforward, although it is possible, one ends you with a solution that is task-oriented rather than universal.

Where Filemaker can make up for a multitude of shortcomings is in its delivery of data which is superb. Which is why people are so concerned about Java drivers.

If as foodsman suggests FMP7 will be fully relational (and presumably SQL compliant) they must be working 24x7 at Filemaker to achieve this in the next 18 months.

[Kurt Knippel]

To answer the question on relational operators, Filemaker implements only the EQUALS operator. You can implement other operators through use of ranges, multi-keys and calculations, but it would make things much easier if Filemaker's relational model allowed for the other operators.

SQL is a method of defining pretty much everything in a database. It can define the tables, the rules, the relationships, the finds, the sorts, the displays, etc.

Filemaker provides for all of these functions through other means and methods. Most other RDBMS simply relay on thier SQL implmentation for this.

This is both an advantage and a disadvantage, because of the complexity and flexibility of SQL. Filemaker is able to provide a better "user" experience by implementing this functionality in the way that they did, however they had to sacrifice compatibility with SQL systems.

I would like to see Filemaker implement SQL for Finds, Sorts and Relationships, with thier existing interfaces used basically as wizards to create the underlying SQL code, but still hiding it from users unless they want to actually edit the code themselves.

As an example, most of the SQL diagramming software will do similiar things, where a user defines the tables, keys, rules and relationships in a visual environment and/or with wizards. The app will then generate all the underlying SQL code necessary, while the user never actually has to touch it if they do not want to.

[BobWeaver]

Q: What can other databases do that Filemaker can't?

A: So far, I haven't found anything. Excepting, of course, things that are size related (and those haven't been a limitation for me so far). I've been working with it since it was FileMaker II. It isn't always as clean as I would like, but as far as searching, sorting, organizing, and general manipulation of data, I've always found a way to do everything I've wanted.

[Kurt Knippel]

Personally I do not think that there is any generic answer to the above question. Filemaker is a fully featured RDBMS just like many others. Each system has its own ways of accomplishing things, some are automatic or built in, some require programming, some need manual attention and maintenance (ohh my gawd the frequent compacting and index building that dBase solutions needed).

Oracle does things the Oracle way, which is different from the SQL Server way, which is different from the Filemaker way, which is different from the 4D way.

The chief different I see is that the given solution may need something that the Oracle-way offers and this will make Oracle the most likely candidate.