File sizes (Maximum number of fields)

[Jarvis]

Can somebody tell me anything about the limitation of files sizes?

I'm limping along here trying to construct a database to use at my cabinetshop. I'm also working real hard to make sure that this database doesn't start to become more interesting than my cabinetshop.

For this reason I am reconciled to my lack of finese.

I'm sure that someone who knew more than me could do what I am doing much more succinctly than I am doing it.

One of my databases has about 120 fields.

This database calls out all of the parts of a cabinet and references an

X-Y & Z dimension for each part. Some of the math originates from related files but I try to keep as much possible within discrete files.

For example, everything you need to know about a refrigerator cabinet is in the refrigerator cabinet file.

Is there a limitation to how many fields a file can contain?

Is there a size, beyond which the files become unwieldy?

I am using a MacIntosh G4 with Filemaker 6.

A typical file has about 500K worth of data.

Also: Can anyone recommend a tutorial for someone with as remedial background as myself?

Thanks for your patience.

Jarvis

[Fitch]

[color:"blue"] Is there a limitation to how many fields a file can contain?

No, but once you get up into the 100+ range, I'd seriously look at whether your structure would be better served by some simpler, related files.

[color:"blue"] Is there a size, beyond which the files become unwieldy?

At 2 gb, your files will die. "Unwieldy" depends on computer/network speed. A G4 with Filemaker 6... about 500K worth of data should be no problem at all. But the unwieldiness of working with hundreds of fields, that's a different problem altogether. Be sure to adopt some kind of consistent scheme for naming your fields, e.g. start calc fields with "c" and globals with "g." Check this out:

http://www.coresolutions.ca/resources/standards.lasso

[color:"blue"] Can anyone recommend a tutorial ...?

http://www.fentonjones.com/FM101.html

[Ugo DI LUCA]

  Quote

I'm also working real hard to make sure that this database doesn't start to become more interesting than my cabinetshop.

You know what ?

This happened to me this year. Business gone, sold or on sale....

FM Living on its way

[Paolo]

If you have so many of fields to describe something (cabinet) change approach!

Break your cabinets db into two databases:

DB 1: CABINETS

cabinet_id (primary key, serial number)

name

importantInfo1

importantInfo2

importantInfo3

DB2: CABINETS DETAILS

detail_id (primary key, serial number)

cabinet_id (foreing key)

detail type (size, color, width, height,......)

detail data (it contain the size, the color, the width,.... depending on the detail type)

This way you'll work a lot better!!!

btw:

you can also make a third database with "DETAIL TYPES"

[Paolo]

i forgot a couple of things:

1) keep importantInfo info into FEW fields in file DB1. Only main data about cabinets.

2) Dont make several cabinet files to store different cabinet files (one file for refrigetarors, one for xxx cabinets, one for yyy cabinets) This is BAD design!!

3) if the db is going over the GB due to great quantity of "MEDIA" content (images, graphs, ...) keep the content that is not searched or edited frequently in separate files (PDFs, JPGs, ecc) and store just a reference to the file into your db. With an applescript or its window-equivalent you should be able to open the file from the reference.

Follow these rules.

Worry about performance (and good design) if you are going over 50000 records

Worry about size if you are going over 500000 records.