Dealing with large number of fields/possibilities

[KMKelly]

Someone asked me to compare using Access to Filemaker (which I know absolutely nothing about). The major issue is that the database would be to collect information physiologic info and for each major part of the body or organ system, all sub-sections would be listed with a check box. The person who wants to do this estimates around 500 different elements which could be used in any combination.

What I was told was that Filemaker would allow him to set this up and click on any number of check boxe within a given grouping and all of the data would be saved to one field and he wants to know how hard it would be to do this in Access. I know it could be coded to concatenate a number of selections into one field, but it seems messy and it would make querying and reporting the data more difficult. In general, with stuff like this I have just had one field for each check box, but this is a lot more fields than I have ever dealt with.

Does anyone have experience working with large numbers of fields. Are there potential issues using the elements as separate fields? Is there any benefit to doing what he wants to do and combining elements into groupings? Also, I tend to lean toward Access because I know it, but is there any benefit to him staying in Filemaker?

Thanks for any input.

Kristin

 

[MichaelRed]

Is the issue their abillity? Or Yours? Who wouuld actually implement the db?

My general approach would be to recommend the language product the implementer is comfortabe with. Other considerations obviously apply, including any organizational 'culture' (boss wants it this way ...), opportunity to expand one's knowledge, schedual constraints, wheateher the projeect is sponsored (e.g. paid for) or a personal persuit).

Answers to these (and other) relevant issues would dictate any difference in the final soloution I would recommend.





MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[KMKelly]

In response to the questions above. I think I was mostly being asked how difficult this would be to do in Access, but ultimately the person in question would need to hire someone to do this for them. He has experience in both packages as a user, but isn't prepared to do the development of the application. It is in a related division, but not something I would be involved in at all.

Ulitimately, I am curious though about the benefits or problems in setting the database up with so many individual fields (yes/no), versus storing the data in some other fashion.

Thanks.

 

[MichaelRed]

Then, it becomes the chiken vs. egg issue. Which comes first the decision of which 'language'/development package or the best qualified individual?

I wouldn't generally think that any of the 'PC' databases would be my choice for 500 fields for a record, and it could not be in Ms. A. (Jet), so it would either need to be a relational process or use some other db engine. Then, You get into the number of (concurrent) users, where Ms. A., at least, does reasonably well for up to X (where "X" is a disputed number, some place this figure as low as 5 or 10 but I have had 'good' experience with up to about 75 users).

Other features of the overall situation also need to addresses, such as the total size of the DATA set, the network arrangement and administration. the number of users overall and the number of users who will enter new data, the number who will modify the data, how many reports (and how complex) there will be, just to mention a few.

For me, there are far to few details to make a 'solid' recommendation, but I would not see a problem in the use of Ms. Access, at least as the front end (user interface), but the back end would need more information / consideration. Ms. has ventured into the "ODBC" realm and been reasonably sucessful, so the actual database engine could easily be changed to a heartier system at alomost any point in the development or even deployment with much less cost / effort than in the not so distant past. While an approach using the Jet engine with relational tables is certainly feasable, it might be almost as easy to implement the "MSDE" (aka Mini SQK Server) and just prepare for the larger scene from the beginning.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places