wrwatson2003 wrote: > About how many records do you have? This may help me with making my > decision; that is if you can give me a practical "real world" > scenario that will give me something to compare my project to. > > Thanks in advance! > - William > William,
It sounds like your project requires skills and experience (i.e. in data modeling) that you may not have acquired yet. I suggest you take a course (or at least buy a book) on data modeling. I'll try to give you a "sixty second" overview of data modeling, but it is beyond the scope of this forum to go into this too deeply. If you still can't get it to work, you may need to hire someone to do this part. There is no hard and fast rule about having more fields or more tables. What you need to do is represent (i.e. model) your data correctly. Since you haven't given any details about what the 90 fields are that you need to store, it is impossible for us to suggest an appropriate model. Here is a quick example of how the same set of data can be modeled differently. Hopefully you can translate this example into useful concepts for modeling your data. Lets say we need to store information about customers...like name, mailing info (i.e. street, city, state, zip), phone number and e-mail address. We could store this info in one table called Customer. Customer now has the following fields: name, street, city, state, zip, phone number and e-mail address. This works fine as long as each customer only has one mailing address and one phone number and one e-mail address. However, if they have two phone numbers, now we need to create two records WITH DUPLICATE INFO except for the phone number. This is a waste of space. Add another field, you say? True, you could do this. But then, for every customer that only has one phone number, you're wasting the space in the second field. Plus, what if someone has a third phone number? Do you keep adding fields? No, what you do is model your data better. This is called normalization. There are about 5 or 6 levels of normalization which I won't go into here (mainly, because I forget what they all are ;-) ) What we've done is identify some "entities" and the "relationships" between those entities (in Entity-Relationship diagram (aka ER diagram) terms). The entities are Customer, Address and Phone and Email. We also know that each customer can have multiple addresses (home, work, vacation, etc.), multiple phone numbers (home, work, cell, etc.), and multiple e-mail addresses (home, work, etc.) Each entity in an ER diagram is a separate table. So, we now have a Customer table, an Address table, a Phone table and an Email table. To represent the relationships, we'll need a unique identifier in the Customer table (say, CustomerID). We'll also add a CustomerID column to the other three tables, however it will NOT contain unique values in those tables. I'll explain why in a second. Now if we have one customer with one address and two phone numbers and no e-mail address, we can store the information more precisely. The Customer table will have one record with CustomerID 1 and name "Joe Blow". The Address table will have one record with CustomerID 1 (so we know that this address record links back to Joe Blow) and street, city, state and zip fields with the appropriate info. The Phone table will have two records. Both records will have a CustomerID of 1 (so we know they're both Joe's phone numbers) but each record will have a different phone number. Record 1 will have CustomerID 1 and phone number 555-123-4567 and record 2 will have CustomerID 1 and phone number 555-098-7654. The Email table will not contain any records. If we add a second Customer with only an Email address. The Customer table now has two records (CustomerID 1 - Joe Blow and CustomerID2 - Jane Doe). There will be no records in the Address or Phone tables for Jane, but there will be a record in the Email table with a CustomerID of 2 and an address of [EMAIL PROTECTED] ). This is the basic concept. It can get more complicated. You may need to model two customers at the same address (i.e. husband and wife's home address) plus they work together too. This is called a many-to-many relationship. You could also de-normalize the phone and email tables by combining them into one table called Contact with an additional field indicating the type of contact information in the record (i.e. home phone, work e-mail, cell phone, etc.). This concept may work for your project. Assuming each of your 90 checkboxes is an "option" chosen by a customer, you could have a Customer table (with CustomerID and Name fields) and an Option table (with CustomerID, CheckboxName and Checked fields). Link the two tables using the CustomerID and you could have up to 90 records per customer in the Option table...one record for each checkbox that is checked. Sorry if this is a bit long winded. Hopefully you'll find it useful, though. Best regards, Jim at iDimensionz.com -- http://www.iDimensionz.com Professional web site design and affordable web site hosting. ------------------------------------------------------------------------ Get Firefox! <http://www.spreadfirefox.com/?q=affiliates&id=38044&t=84> – Get the new open source web browser, FireFox, and enjoy features like pop up blocking, tabbed browsing and MUCH more! Get Thunderbird! <http://www.spreadfirefox.com/?q=affiliates&id=38044&t=178> – Get the new open source e-mail client, ThunderBird, and enjoy features like integrated spam filter, privacy protection, integrated RSS reader and MUCH more! ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/CefplB/TM --------------------------------------------------------------------~-> The php_mysql group is dedicated to learn more about the PHP/MySQL web database possibilities through group learning. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/php_mysql/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
