Как лучше организовать схемы таблиц БД (контакты-персоны-компании)?

Question

[Vitaly Melnikov]

Думаю как лучше организовать таблицы.
Суть: Хранилище сущностей, которые могут быть персонами или компаниями, некоторые их которых оказывают строительные услуги, некоторые юридические. У каждой сущности может быть 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 - [phone], т.е. поступиться размером БД, для снижения затрат на представление, при выводе 100-1000 телефонов?
5. Что лучше делать с дублирующими мейлами Яндекса? @ya.ru yandex.ru
Как вариант думаю в базе все приводить к @ya.ru, т.е. во всех формах поставить условие автозамены.

Answer 1

[Vitaly Melnikov]

Вопрос с дублирующими мейлами Яндекса закрываем - останавливаемся на проверке и приведению к ya.ru при сохранении в базу.

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

Таблица - contact
Таблицы - contact_person и contact_company
Таблицы - contact_phone, contact_email и contact_social

Я правильно понял, что для выполнения этих задач делать связку где главная contact, а от нее идут к примеру contact_person и contact_phone

--- Добавлено 24/01/2018 ---
В общем для себя решил так сделать, делюсь может кому поможет
Таблица - contact для связки
В ней тип (person/company) и его ID
C другой стороны тип(phone/email/social) и его ID

Answer 2

[Boris Köln]

1. Сущности принято именовать в единственном числе.
В contact только общие поля. Дополнительные в contact_person и contact_company (PK является FK).

2. Транслитом: inn, kpp, okpo, opf

3. Мобильный/рабочий - разными store_contact.type

4. Телефоны все приводить к единому формату E.164 перед вставкой в БД

5. Email все приводить к единому формату (в нижнем регистре и, возможно, с заменой ya.ru) перед вставкой в БД

Answer 3

[vism]

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

Плюс получите большие потери времени, чтоб закодить эту универсальность