james.saldana

larryjw said:

longterm said:

LARRYJW said this: "In FileMaker it's impossible to actually build an application in which the tables are true relations (which is what it means to be a relational database: table == relation)." That is pure nonsense, and he clearly has no experience with FileMaker; I have solutions with over 100 related tables in them; one can either put all the tables into a single database file, or have them spread among multiple files. In either case, the tables can be as relational as one might wish. The tables don't have "common fields;" the design schema allows the user to relate tables just as one would with SQL. LARRYJW needs to look at it before he makes incorrect assertions.

In fact, FileMaker also has the ability to use SQL queries for finding and using data. For the record, FileMaker became fully relational back in the early 90s.

Thank you longterm for proving my point. Relational databases are NOT relational because you can "relate" tables. In the language that is just a JOIN (inner join, left outer join, right outer join, full outer join, natural join, semi-join). The ability to JOIN tables is NOT what makes a database a Relational Database. In the almost 50 years since Codd wrote his seminal paper, hundreds of books, most accurate, have been written about this topic -- clearly, none of which you have read or understood. Many books are simply wrong since too many in the field simply want to make a buck and since Relational Databases became the marketing word of choice, every database in existence was marketed as Relational regardless of whether it was or not. This is too much the American Way -- fake it. 

To be a relational database, the things generally called Tables must be Relations. Relations are a general mathematical concept. For each table is a set of rows, and the columns are set of functions of the columns which are the KEY to each function (each column) of the table. In no way does FileMaker implement the Relations and in fact, my experience with FileMaker is that it is impossible to implement Relations in FileMaker when implementing any application. 

Most tables in Filemaker must contain fields which not functions of the supposed key of that table. Summary fields are typical examples. Global fields are another. They're values are not a function of the key of the row in which they exist. This is big deal and not some exercise in academic trivia. 

Further even Oracle XE is more than a capable database server out of the box, and you don't have to spend a bundle buying a Filemaker Server -- overpriced and underperformance at any price. 

Critically, Filemaker does not see the "database" as independent of the reports. If the table takes part in multiple reports, then it is typical that the table has multiple fields which are created for the multiple reports it belongs to. 

As I said, the best freely accessible database is Oracle XE. It definitely has limitations over its enterprise version -- only uses one cpu, limited to 11GB of data, and true of all Oracle databases, to my chagrin, Oracle does not support large text fields or containers as relational database fields (in a formal transparent way) unlike its trivially easy-to-use versions in FileMaker, Access, MySQL (though Apex now handles these kinds of fields easily). But, like its enterprise versions, Oracle XE databases also support the very complete procedural programming language PL/SQL which at all levels blows every other database application system out of the water, especially Filemaker and even Access with in Basic language. Oracle also supports the Java language within the database (which it did long before Oracle bought Sun).