Форум пользователей MySQL

Думаю как лучше организовать таблицы.
Суть: Хранилище сущностей, которые могут быть персонами или компаниями, некоторые их которых оказывают строительные услуги, некоторые юридические. У каждой сущности может быть 0 или несколько телефонов, мейлов, и других средств связи. Кол-во около 500 000 записей.
Нужно организовать вывод персон, компаний, поиск, по всем полям, проверка и объединение дубликатов по mail/phone и т.д. поиск то телефонам/мейлам на вывод и компаний и персон, по компаниям возможность увидеть связанных с ней персон. Синхронизацию с другой базой - если у связь этого телефона/мейла и т.д. is_builder = 0, а у них is_builder = 1, то при синхронизации у нас меняем на is_builder = 1, не знаю куда лучше это поле к персоне или хранилищу

Планы по организации таблиц
Таблица contacts
id
type - enum тип company/person
для person свои уникальные поля - full_name, last_name,...passport...birthday......
для company свои уникальные поля - company_name, ОПФ, inn, kpp, юр.адрес
статусы для обоих - is_builder/is_lawer
created_at
updated_at


Таблица store_contacts - храним в одном месте мейлы, телефоны, урлы, скайпы и т.д., разделяя по типам
id
contact_id
type - enum тип мейлы, телефоны, урлы, скайпы и т.д
value
is_main


Теперь какие вижу проблемы
1. Две таблицы с одной стороны более быстрый поиск, с другой много лишнего, наверно проще разделить на две таблицы: persons и companies у каждой свои уникальные поля, а в store_contacts, тогда как быть?
Заменить один столбец contact_id на 2 столбца: person_id и company_id, получиться немного мусора лишний столбец, для каждой строки. Плюс только при разделении как понимаю я могу получить связь персоны с компанией, которая нужна.
2. Какие обычно английские названия столбцов используются для реквизитов российских компаний?
3. У телефонов и мейлов также нужны особенности по телефонам тип: мобильный, рабочий и т.д., по мейлам статусы - подтвержден, не потвержден, разрешение на разные виды подписок и т.д.
Как здесь лучше быть, чтобы не потерять в скорости обработки - выводить специфику в отдельные таблицы и делать связи с store_contacts?
4. Что делать с номерами телефонов сейчас в одном поле phone - 79991112233, стоит ли для ускорения добавить второй столбец с отформатированным форматом к примеру phone_formated - +7 (999) 111-22-33, т.е. поступиться размером БД, для снижения затрат на представление, при выводе 100-1000 телефонов?
5. Что лучше делать с дублирующими мейлами Яндекса? @ya.ru yandex.ru
Как вариант думаю в базе все приводить к @ya.ru, т.е. во всех формах поставить условие автозамены.
6. Что можете посоветовать из визуального софта, который выгрузит схему БД