Home/ Questions/Q 517151
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T07:48:17+00:00

I’m working on creating a membership-based web application. In order to become a member,

  • 0

I’m working on creating a membership-based web application. In order to become a member, you must fill out a lengthy membership application that qualifies your business. Once the application is complete, it goes to the admin of the site for approval. The application contains about 60 or so questions to be answered. Perhaps 25% of those questions will be relevant to your member profile once you are approved. The rest of the questions are used only in the review process and are never referenced once a “prospect” becomes a “member.” Here’s my question:

Should I combine all of the prospect questions with all of the member information in one table or split it up somehow? The relationship is 1-to-1 so that makes me feel like it should be in one table. The part that makes me feel like it should be in separate tables is that much of the application information becomes irrelevant after a prospect becomes a member. It seems like it would be a lot of wasted space….

The application actually exists already; I’m just overhauling it from ASP Classic to PHP/MySQL with some considerable functionality improvements. The current application has a “prospects” table and a “members” table. When a prospect becomes a member, the current application copies the relevant data over to the members table and marks the prospect as deleted with a bit column called “deleted”……just for more background…

EDIT:
I’ll be migrating the database from MSSQL2005 to MySQL

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would use the existing scheme. It may seem like some wasted space, but it has these benefits:

    Your members table will have only info from companies that are actually members. It will not have records for unreviewed or rejected prospects.

    Your prospects table will not be changed when a user edits their profile, so you will have a historical record of the actual application. This could be handy if the profile changes so much that the company would not be accepted if they had applied with the new information.

    And, of course, when you’re looking at a prospect, you don’t have to join two tables. A minor point, but why go through it if you don’t have to.

    • 0