Модель базы данных заявки на членство

Question

Я работаю над созданием веб-приложения на основе членства. Чтобы стать участником, вы должны заполнить длинную заявку на членство, которая соответствует вашему бизнесу. Как только заявка завершена, она отправляется администратору сайта для одобрения. Приложение содержит около 60 или около того вопросов, на которые нужно ответить. Возможно, 25% этих вопросов будут относиться к вашему профилю участника после вашего одобрения. Остальные вопросы используются только в процессе рецензирования и на них никогда не ссылаются, когда «потенциальный клиент» становится «членом». Вот мой вопрос:

Должен ли я объединить все вопросы о перспективах со всей информацией об участнике в одной таблице или как-то разделить ее? Соотношение один к одному, поэтому я чувствую, что это должно быть в одном столе. Часть, которая заставляет меня чувствовать, что это должно быть в отдельных таблицах, заключается в том, что большая часть информации приложения становится неактуальной после того, как потенциальный клиент становится участником. Кажется, что это было бы много потраченного впустую пространства ....

Приложение на самом деле уже существует; Я только что перестроил его с ASP Classic на PHP / MySQL с некоторыми значительными улучшениями функциональности. В текущем приложении есть таблица «перспективы» и таблица «участники». Когда потенциальный клиент становится участником, текущее приложение копирует соответствующие данные в таблицу участников и помечает потенциальное лицо как удаленное с помощью битового столбца, называемого «удаленным» ...... просто для дополнительной информации ...

EDIT: Я буду мигрировать базу данных с MSSQL2005 на MySQL

Answer 1

Я бы использовал существующую схему. Может показаться, что это пустое место, но у него есть следующие преимущества:

Ваша таблица участников будет содержать информацию только от компаний, которые на самом деле являются ее членами. В нем не будет записей о непроверенных или отклоненных перспективах.

Ваша таблица потенциальных клиентов не изменится, когда пользователь отредактирует свой профиль, поэтому у вас будет хронологическая запись фактического приложения. Это может быть удобно, если профиль так сильно изменится, что компания не будет принята, если они подали заявку с новой информацией.

И, конечно, когда вы смотрите на перспективу, вам не нужно объединять два стола. Незначительный момент, но зачем это делать, если не нужно.