I've recently started working on a new companies existing system. In my personal opinion the system is a complete mess and the architecture is BAD, but management begs to differ. Im from a SQL background and I'm thus not sure if things work differently in Filemaker so my question: On average, what would you say is a reasonable amount of tables to have and more importantly, how many fields on average per table? How many fields is too much? Currently they have 50+ tables, some of them with an excess of 1000 fields! Surely this cannot possibly be? What role does normalization play in Filemaker? Thanks a million!

Like SQL, Filemaker is a relational database. There are some differences, mostly due to Filemaker's limitations on the types of joins. But basic design (tables, fields and relationships) follows the same rules, including normalization.

how many fields on average per table?

As many as it takes to describe the entity, the whole entity, and nothing but the entity.

Comment,

As many as it takes to describe the entity, the whole entity, and nothing but the entity

Is there a better definition for Entity other than the following:

An entity is a thing or object of importance about which data must be captured. All things aren't entities — only those about which information should be captured.

Information about an entity is captured in the form of attributes and/or relationships. If something is a candidate for being an entity and it has no attributes or relationships, it isn't an entity.

When one tries to make a FM blueprint of how a particular task is done in the real world. It is difficult to determine where one Entity ends and another one begins.

Depending on how you define "Entity" you could end up with rather "big" Entities. By big I mean unmanageable because of too many fields.

Sometimes, the FM novice, like mylself, is tempted to split the academically correct Entity concept into more manageable subentities. Surely, not the smartest thing to do.

So, what is the right thing to do when "your" Entity (the one you think best describes how a task is done in the real world) is rather unmanageable.

Thanks

It's difficult to define "entity" in non-vague terms, because the classification depends on the purpose of the database - i.e. the business rules, and no less their interpretation by the database architect.

For example, "Customers" and "Suppliers" could be separate entities, or a single "Contacts" entity, or both - depending on what one intends to accomplish and at what price.

That's why database design is a creative process that cannot be mechanized - there is no "academically correct Entity concept" (although obviously some concepts can be immediately discarded as incorrect).

That said, how about:

a set of objects that, for the purposes of the database, are similar enough to be treated alike