Jarvis Posted July 7, 2003 Posted July 7, 2003 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 Posted July 7, 2003 Posted July 7, 2003 [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 Posted July 7, 2003 Posted July 7, 2003 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 Posted July 8, 2003 Posted July 8, 2003 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 Posted July 8, 2003 Posted July 8, 2003 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.
Recommended Posts
This topic is 7912 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now